DEV Community: Samy

Add Live Bilingual Tech News to Your Portfolio Site in One Line

Samy — Sun, 02 Aug 2026 20:46:41 +0000

Every portfolio site has the same problem: it's static. A grid of projects, a bio, a contact form — nothing on the page ever changes, which means nothing on the page proves you can work with live data. Recruiters and reviewers skim past it because there's nothing to skim.

The fastest fix isn't building your own API — it's embedding someone else's, and picking one that's actually interesting to look at. Here's how to drop a live, auto-updating tech news feed into any site with a single script tag, using NewTqnia, a bilingual (English/Arabic) tech newsroom with a free embeddable widget.

Why this is a good portfolio move, not just decoration

A static "About Me" page tells someone you can write HTML. A page with a live-updating feed tells them you can integrate a third-party service, handle async content, and think about internationalization (this one supports English and Arabic out of the box) — all real, hireable skills, for the cost of one script tag.

Step 1: Build your embed

Go to newtqnia.com/en/widget. It's a live configurator, not a docs page — every option you touch updates a preview instantly:

Content: custom heading, number of articles, language (English or Arabic), category filter (Artificial Intelligence, Robotics, Space, Health, and others), and ordering (latest first or most popular)
Appearance: card / list / compact layout, horizontal or vertical orientation, light / dark / automatic theme, accent color, and toggles for images and summaries Pick settings that match your site — a compact, dark-themed, "Artificial Intelligence"-filtered list looks noticeably more intentional than the default.

Step 2: Copy the generated snippet

Once you're happy with the preview, the page generates a ready-to-paste embed code block for you — copy it as-is. It'll look roughly like a single <script> tag referencing your chosen configuration, something like:

<script
  src="https://newtqnia.com/embed/widget.js"
  data-lang="en"
  data-category="artificial-intelligence"
  data-count="5"
  data-theme="dark"
  async
></script>

(Use the exact snippet the configurator gives you — it encodes the specific options you picked, so don't hand-type this one from memory.)

Step 3: Drop it into your site

Paste the snippet wherever you want the feed to appear — a sidebar, a footer section, a dedicated "Now Reading" panel on your homepage. The widget renders inside an isolated Shadow DOM, so it won't inherit or clash with your site's existing CSS, and it won't leak its own styles back into your page either. That's one less thing to debug.

One thing to check if your site enforces a Content Security Policy: you'll need to allow newtqnia.com for script-src, connect-src, and img-src, or the widget will silently fail to load.

Step 4: Make it yours

A few ways to push this past "I copied a script tag":

Toggle the language dynamically. Add a small button on your page that swaps data-lang between en and ar and re-mounts the widget — a tiny but real demonstration of handling i18n on the client.
Match it to your site's theme. If you already have a dark-mode toggle, wire it to the widget's theme option so the feed switches with the rest of the page.
Filter by what you're into. If your portfolio is robotics-focused, filter the widget to the Robotics category instead of leaving it on "All categories" — small detail, but it shows you're not just pasting boilerplate. ## Want to go further than the widget?

NewTqnia also ships a public REST API with an OpenAPI 3.1 spec, official PHP and Node SDKs, and an MCP server for AI agents — worth a look at newtqnia.com/en/developers if you'd rather build your own feed UI from scratch instead of using the pre-built widget. That's a meaningfully bigger project, but a great follow-up once the one-line version is live.

Either way, it's a five-minute change that turns a static portfolio into one with something actually happening on it.

I Built a News API Before I Had Users. Here's What I'm Learning.

Samy — Fri, 24 Jul 2026 04:44:01 +0000

The API went live on a Tuesday. I had no idea who would use it.

I was building NewTqnia, a bilingual technology publication in English and Arabic, and the requirements kept expanding. Website, RSS, JSON API, embeddable widget, browser new-tab page, structured timelines—each one wanted the same content delivered differently.

That raised a question I still don’t have a clean answer to:

How do you support six delivery surfaces without building six disconnected products?

This is not a success story. It’s a set of tradeoffs, some working, some questionable, and a few I’m actively looking to undo.

The API: small on purpose

The first public version of the Daily Digest API does almost nothing.

curl "https://newtqnia.com/v1/news/today?locale=en&limit=5"

That’s it. today, latest, two query params, no API key. Sixty requests per minute, ETag support, sensible Cache-Control.

I could have shipped categories, tags, search, recommendations, and analytics endpoints on day one. But a large API with unstable contracts is just a private API that happens to have public documentation. I wanted the opposite: a small surface that would not embarrass me if someone actually built against it.

The awkward part? Developers can’t ask for endpoints they don’t know are possible. So “wait for demand” is a safe strategy, but maybe not the right one. I’m still figuring out where the line is between “prudently small” and “uselessly small.”

The widget problem: isolation is expensive

Some people just want headlines on their site without writing HTTP clients. So I built a script:

<script
  async
  src="https://newtqnia.com/news-widget.js"
  data-count="5"
  data-locale="en"
  data-layout="cards"
  data-orientation="horizontal"
  data-theme="auto"
  data-accent="#03c0f9"
  data-order="latest"
  data-show-image="true"
  data-show-summary="true">
</script>

The widget builder generates this and shows a live preview.

Here is the part nobody warned me about: every isolation strategy moves complexity somewhere else.

Iframe? Strong style isolation, but responsive sizing becomes a negotiation with the host page.
Shadow DOM? Protects against CSS leaks, but theming and accessibility traversal get weird.
Plain script with scoped CSS? Familiar to embedders, but one !important rule on the host side and your layout collapses.

I went with the simple script and data-* attributes for now. I’m not convinced it’s the long-term answer. If you’ve shipped an embeddable widget, I’d genuinely like to know: did you regret not using Web Components from the start?

Timelines are not articles

A news article describes a moment. A timeline has to explain how moments relate across years.

We publish timelines on things like the evolution of generative AI and the history of the Internet. Internally, these are not long articles. They are collections of events with fields like:

Exact or approximate dates
Event types and importance levels
Primary and secondary sources
Related links
Event-specific media
Bilingual captions and alt text
Attribution and licensing

This makes the content reusable, but it also introduces editorial problems that code can’t solve. What do you do when two reputable sources disagree on a date? How do you mark a timeline as incomplete without undermining it? How do you represent a source that is credible but secondary?

I’m also unsure about the public format. Custom JSON is easy to design. JSON-LD or an existing event vocabulary is harder but more interoperable. If you were consuming timeline data from an API, which would you prefer?

Bilingual support starts in the data model

Arabic is not “English with different words.” It needs RTL layout, different typography, localized dates, and interface decisions that don’t always mirror the English side.

For structured content, the simplest model is explicit bilingual fields:

{
  "title_en": "The Transformer rewrites the architecture of language AI",
  "title_ar": "بنية المحولات تعيد صياغة هندسة الذكاء الاصطناعي اللغوي"
}

This is easy to query and validate when you have exactly two languages. It becomes ugly at five or ten. A normalized translation table scales better, but it adds joins, fallback logic, and publishing-state complexity that I don’t need yet.

My current rule: reconsider the model before adding a third language, not before. Premature normalization is still premature optimization.

Media became a subsystem by accident

Once timelines started using event-specific images, storing a single URL wasn’t enough. A useful media record now needs:

A stable internal ID
Processing status and responsive variants
Dimensions and file type
Bilingual alt text and captions
Original source, attribution, and licensing
A relationship to either a timeline or an individual event

Images are processed into multiple sizes and formats. Events reference the internal asset, not an external URL. This keeps accessibility metadata attached to the thing it describes, and it avoids tying published pages to the uptime of some third-party host.

The part I can’t automate: whether the alt text is actually good. Validation checks for presence. It does not check for usefulness.

Distribution creates an attribution boundary

The more portable you make content, the less control you have over how it’s used.

Return only a title and URL, and the API is barely useful. Return full articles, and you’re inviting unattributed republication. Summaries are a middle ground, but even summaries get aggregated into faceless feeds.

Right now the API asks consumers to preserve article URLs and display visible attribution. That is a social contract, not a technical one. I’ve looked at signed content, stricter terms, metered access, and API keys. Each one raises the cost of legitimate experimentation.

If you’ve designed a public content API, how did you decide how much to give away?

What I would do differently

Start with the timeline data model earlier. Treating timelines as articles first meant a migration I could have avoided.
Question the embed strategy harder. A script tag feels like the easy path until you’re debugging CSS specificity on a site you don’t control.
Document the API’s philosophy, not just its endpoints. Developers need to know why it’s small before they decide whether to build on it.

Questions I’m stuck on

If you were reviewing this system, I’d value your take on:

Scope creep: At what point does a small REST API need categories, tags, or search?
Push vs. pull: Would webhooks for new stories be useful, or does RSS already solve that?
Embed interfaces: Is a data-* script still a good integration format in 2026?
Web Components: Do they actually solve the widget isolation problem, or just shift it?
Timeline formats: How would you represent sourced historical events in a public API?
Multilingual models: What is the least complicated model that still supports future expansion?
Content boundaries: How much article content should a public news API return?
Versioning: Which caching or contract mistakes should I fix before the API grows?

You can poke at the current implementation through the developer page, the widget builder, and the live timeline collection.

If one part of this system deserves to be simplified, replaced, or avoided entirely, which one is it?

2000 public APIs for your Next Project

Samy — Tue, 03 Jan 2023 06:49:44 +0000

Consuming API is a crucial part of learning any programming language. There is a need to integrate different systems almost in any programming project.

Mobile Apps, Websites, CRM, ... and the list is long, all require integration with other 3rd party or even internal APIs.

Practicing such will require an API to work with, and in this post, I'm shedding light on my recent work, the Public API Directory.

In this directory (APIsList) , I've compiled more than 2000 public APIs from the community and also by the direct share of the API owners, to make it easier for any one looking for his next project idea, or even integrating with an existing system.

The directory list some decisive information about each API with powerful search engine to make it easier for you to choose the correct API for your need. It does also come with pre-defiend lists such as Open Source APis list, Free APIs and APIs with CORS support.

I hope you will enjoy it, and please drop any suggestion or critisism to make it better in the comments below.

The IBAN API

Samy — Sun, 22 Aug 2021 09:52:42 +0000

I wanted to share my latest product with the community, which is the IBAN validation API.

This product offers a way of validating the IBAN and getting the bank metadata from it, such as Bank Name, Branch, address and BIC, ...

The product is growing daily by the usage of its customer whereas of today it covers more than 100 countries around the world.

I would like to share the product with the community where it will benefit you if you are in the Fintech, e-commerce, accounting, or any related sector and you require your customer IBAN where this API will boost and enhance your user experience and your system acceptance rate.

The IBAN API can be accessed through this URL.

Please let me know your thoughts and suggestions.

I've created the online tools platform

Samy — Sun, 13 Dec 2020 07:49:34 +0000

So, as many other developers, I've many tools to be used daily, such as JSON Viewer or hashing strings :)

My list of daily used tools is growing with some limitation on some tools online, as a result, I've decided to build my own tool and share it with the community.

After a few days of work, I've launched the initial version of devtools360.com intending to provide more than 100 useful tools for different use cases.

Since then I'm adding tools every week, for instance, the most recent tool was the OCR Tools, Mac address Lookup tool, and website DNS checker tool.

I thought it would be better to get dev. community feedback on what has been done, and what should be done next to make this platform more convenient and easier to use.

So please let me know your thoughts :)