Daniel Opitz

The "Slim 4 eBook Vol. 3" is now available! 🎉 #php #slimframework ko-fi.com/s/3698cf30f3

@SumitM_X There should be no JWT for a public API.

The Tech Lead says your public API and internal API both should accept the same user JWT. What should be your reply ?

@OskarStark Another underrated advantage of PHP (and dynamic/interpreted languages in general) over classically compiled ones like Java or C#: Coding agents have access to the source files of the packages.

Hot take: The PHP ecosystem in 2026 is more innovative than most "modern" stacks. Symfony's DX improvements, static analysis with PHPStan, native attributes, fibers... We just don't mass-market it on Twitter every 5 minutes. 🤷

@brendt_gd Nice, but in this example it's not clear what method would be called if you pass a string.

Am I the only one who wants this??

@Dave_DotNet No, because this suffix adds noise without much benefit. It's also redundant because the return type already signals "this is async".

Are you still adding an 'Async' suffix to your async methods in #dotnet? Why / Why not? 🤔

JWT tokens vs cookies

@ECMAScript4 Germany isn't bad at software, it's bad at turning software into global products. SAP dominates ERP, Nextcloud leads in self-hosting. What's missing: speed, risk "appetite", product focus. Engineering culture ≠ startup culture.

Germany being so bad at software is so shocking to me, like none of the engineering culture was transferred over?

@AntonMartyniuk HATEOAS never worked in real world scenarios. This is why we call them RESTful and not REST.

𝟵𝟬% 𝗼𝗳 𝗔𝗣𝗜𝘀 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗥𝗘𝗦𝗧𝗳𝘂𝗹 Web APIs can't be fully RESTful without a GPS 👇 According to Richardson's REST Maturity Model, there are four levels of REST APIs: • Level 0 (Swamp of POX): Plain XML or JSON with a single endpoint. • Level 1 (Resources): Separate resources with unique URIs. • Level 2 (HTTP Verbs): Proper HTTP methods (GET, POST, PUT, DELETE, PATCH). • Level 3 (HATEOAS): APIs provide links dynamically, guiding clients through possible actions and states. Most APIs are stuck at level 2, missing the 𝗛𝗔𝗧𝗘𝗢𝗔𝗦. HATEOAS: Hypermedia as the Engine of Application State. Why should you care? Without HATEOAS, your clients are tightly coupled to endpoints, causing costly changes and maintenance. 𝗛𝗔𝗧𝗘𝗢𝗔𝗦 𝗶𝘀 𝗚𝗣𝗦 𝗳𝗼𝗿 𝗔𝗣𝗜𝘀: ↳ Dynamically guides API clients through the available actions and states using embedded links ↳ Provides directions to navigate routes, HATEOAS gives clients clear paths to interact with your API without hard-coding specific endpoints ↳ This flexibility ensures your API remains robust and easy to integrate, even as it evolves. ❌ Without HATEOAS, the frontend copies business checks from the backend to determine whether to put an "update" button or not. Often, backend and frontend can go out of sync, leading to bugs. ✅ With HATEOAS, server sends the "Update Link" to the frontend. No need to re-implement complex business checks to determine whether a user is allowed to update the resource. This approach shifts complexity to one place — the backend, where it belongs. Are you integrating HATEOAS into your APIs, or are they still stuck at Level 2? Let me know in the comments below 👇 ♻️ Follow me @AntonMartyniuk and repost this to help others ▶️ Subscribe to my free newsletter to learn how to craft better Web APIs: ↳ antondevtips.com/?utm_source=li… #dotnet

𝗪𝗵𝘆 𝗱𝗼𝗲𝘀 𝗚𝗼𝗼𝗴𝗹𝗲 𝗿𝗲𝗰𝗼𝗺𝗺𝗲𝗻𝗱 𝗠𝗼𝗱𝘂𝗹𝗮𝗿 𝗠𝗼𝗻𝗼𝗹𝗶𝘁𝗵𝘀 𝗶𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀? Over the last decade, we have witnessed a significant trend of utilizing microservices across various industries. We were building systems for a few hundred or thousand users and wanted to know how to make a system for millions of users. This was over-engineering and needed to be corrected. Why was it wrong? Because the development lasted a long time, we created incredibly complex systems, which are hard to maintain. This is especially true for startups that must go fast and stay simple. A recent paper by authors from Google found that most of their developers split binaries for one of the following reasons: to improve performance, enhance fault tolerance, and establish abstraction boundaries, allowing for flexible rollouts. Yet, splitting applications into microservices has its challenges: 🔹 𝗜𝘁 𝗵𝘂𝗿𝘁𝘀 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲. The overhead of serializing data and sending it across the network is becoming an increasingly significant bottleneck. 🔹 𝗜𝘁 𝗵𝘂𝗿𝘁𝘀 𝗰𝗼𝗿𝗿𝗲𝗰𝘁𝗻𝗲𝘀𝘀. It is incredibly challenging to reason about the interactions between every deployed version of every microservice. 🔹 𝗜𝘁 𝘁𝗮𝗸𝗲𝘀 𝘄𝗼𝗿𝗸 𝘁𝗼 𝗺𝗮𝗻𝗮𝗴𝗲. Rather than having a single binary to build, test, and deploy, developers must manage n different binaries, each on its release schedule. 🔹 𝗜𝘁 𝗳𝗿𝗲𝗲𝘇𝗲𝘀 𝗔𝗣𝗜𝘀. Once a microservice establishes an API, it becomes easier to change by breaking the other services that consume the API. So, they proposed the following approach: 𝟭. 𝗪𝗿𝗶𝘁𝗲 𝗺𝗼𝗻𝗼𝗹𝗶𝘁𝗵𝗶𝗰 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 that are modularized into logically distinct components. A component is a long-lived agent, similar to an actor. 𝟮. 𝗟𝗲𝘃𝗲𝗿𝗮𝗴𝗲 𝗮 𝗿𝘂𝗻𝘁𝗶𝗺𝗲 𝘁𝗼 𝗱𝘆𝗻𝗮𝗺𝗶𝗰𝗮𝗹𝗹𝘆 and automatically assign logistical components to physical processes based on execution characteristics. Therefore, if both components are in the same OS process, they are referred to as regular method calls. However, if they are co-located, calls are executed as remote procedure calls (RPCs) over the network. Runtime decides whether these modules should be collocated or moved to different machines (and scaled, etc.). 𝟯. 𝗗𝗲𝗽𝗹𝗼𝘆 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 𝗮𝘁𝗼𝗺𝗶𝗰𝗮𝗹𝗹𝘆, preventing different versions of an application from interacting. This approach consists of two main parts: a programming model with abstraction that allows developers to write modularized applications and a runtime for building, deploying, and optimizing these applications. They claim that it reduces application latency by up to 15 times and costs by up to 9 times by simplifying application management and deployment. If you want to check the framework that implements the approach from the paper, please visit https:// serviceweaver. dev/. What do you think about this approach? Does it look like EJBs or CORBA?

Almost 2500 people online at #PHPVerse 2025 30 Years of PHP celebration! youtube.com/live/3b0ty1iZ8…

@mjovanovictech The anemic domain model is how it should be.

Still relying on services in your Application layer to perform logic? That’s a sign your domain model is doing too little. If your entities look like plain data containers, you’re working with an anemic domain model. Here’s how to refactor toward behavior-driven design: ✅ Push business logic into the domain ✅ Use methods that enforce invariants ✅ Make invalid states unrepresentable ✅ Rethink service boundaries This makes your code easier to maintain, test, and extend. 📘 I walk through a full refactor, step by step → milanjovanovic.tech/blog/from-anem…

Unpopular opinion: Side projects will teach you more than certifications ever will. Build something. Break it. Repeat.

@DavidKPiano Maybe, because this is what a DI container should do. 😜

I really dislike typing "new" in JavaScript and I honestly can't explain why

@justalexoki yellow, green, some orange or red, some blue and black.

are the lines green or yellow

@EngstromJimmy 0.1 + 0.2 = 0.30000000000000004

This is one reason of many why I choose #Blazor :)

Contribute to open source, learn through self-education or courses, record educational podcasts, or grow your pet project easily with a FREE Rider subscription for non-commercial development. Download and start today 👉 jb.gg/rd-free Spread the word! #dotnet #gamedev

Describe #microservices in 3 words or less...

@davefarley77 Too many problems

@VotrubaT PHP-DI (PSR-11)

Regardless other Symfony or Laravel features, which DI package would you choose? tomasvotruba.com/blog/what-i-pr…

@2sush According to rumours because of Windows 95 and 98.

there was no "Windows 9", there was no "iPhone 9", yes, Both Apple & Microsoft skipped "9", coincidence?