今日已更新 365 条资讯 | 累计 39058 条内容
关于我们

今日精选

HOT

最新资讯

共 39058 篇
第 1449/1953 页
开发者 Reddit r/programming

Is it the end of REST, gRPC, Thrift, SignalR and GraalVM?

Guys! What’s the best way to gather early adopters to evaluate new dev tool that literally just killed REST, gRPC, Thrift, SignalR, DAPR and GraalVM in one shot? The concept is to shift away from writing code to expose any business logic in any specific integration strategy like create REST controllers or provide proto interfaces or expose via subscription to queue events as well as avoid implementing the integration-specific client code to call that rest or gRPC endpoint. Instead of that the question comes when I call “zip” module from Nuget in .net I just use its public methods and handle exceptions. Why if I want to use it remotely I should expose the same method via REST, map it to routes, strange parameters, http codes and next call that on other end? Wy I cannot just say it will be on this remote node so whenever I ca that method to “unzip” my intention just travel over network and execute there? The potential solution is to bridge runtimes on native level. Think of it like intercepting developer intention at abstract syntax tree so when you perform operation in code before it gets executed and just send it to the remote runtime fulfill job there and return result. Wouldn’t be beautiful if you could just call methods of any module regardless if it’s same tech or different and regardless of its in memory or remotely? Just by calling methods? I know I know there are isolation interfaces etc… but if you apply those concepts design facade properly, decide what should be public, and allow to attach to those calls any headers (to still support JWT, NTLM, api Keys etc) and will add support that if method is static it goes stateless if it’s instance it goes stateful with sticky session and give the DevOps ability to change channel between WebSocket, http/2, tcp/ip or any message bus without touching code as it will be just pure method code. It could really work. Think of it. How clean your codebase would be, how much more design would fit your original uml, how much l

/u/pladynski 2026-06-18 05:56 6 原文
AI 资讯 Dev.to

Event Loop - Entendendo uma das bases do Node

O Event Loop é o mecanismo responsável por decidir quando callbacks e continuidades de operações assíncronas devem ser executados. Ele não executa operações de I/O diretamente, mas organiza a ordem em que elas retornam para o JavaScript. Essa arquitetura permite que o Node.js mantenha uma única thread de execução para JavaScript, enquanto delega operações de rede, disco e sistema operacional para componentes especializados do runtime e do próprio sistema operacional. Início Quando iniciamos um processo Node.js, o runtime carrega o arquivo de entrada da aplicação e executa todo o código síncrono disponível na Call Stack. Somente após essa etapa o Event Loop passa a assumir o controle do fluxo da aplicação, verificando continuamente quais callbacks estão prontos para execução. │ timers │ └─────────────┬─────────────┘ │ v ┌───────────────────────────┐ ┌─>│ pending callbacks │ │ └─────────────┬─────────────┘ │ ┌─────────────┴─────────────┐ │ │ idle, prepare │ │ └─────────────┬─────────────┘ ┌───────────────┐ │ ┌─────────────┴─────────────┐ │ incoming: │ │ │ poll │<─────┤ connections, │ │ └─────────────┬─────────────┘ │ data, etc. │ │ ┌─────────────┴─────────────┐ └───────────────┘ │ │ check │ │ └─────────────┬─────────────┘ │ ┌─────────────┴─────────────┐ │ │ close callbacks │ │ └─────────────┬─────────────┘ │ ┌─────────────┴─────────────┐ └──┤ timers │ └───────────────────────────┘ Trecho retirado da documentação principal. Sobre o Event Loop Durante muito tempo tratei o Event Loop como um dos conceitos mais complexos do Node.js. Depois de estudar a documentação oficial com mais calma, percebi que a dificuldade não está no Event Loop em si, mas na quantidade de conceitos diferentes que normalmente são apresentados ao mesmo tempo: libuv, Call Stack, Promises, Microtasks, Sistema Operacional e I/O. Quando isolamos o papel do Event Loop, ele se torna surpreendentemente simples. Definindo os passos e apresentando o iceberg 🧊 O Event Loop não executa trabalho. Ele agenda tr

João Victor 2026-06-18 05:51 8 原文
AI 资讯 Dev.to

Stop Picking Dashboard Icons by Keyword

Most dashboard icon problems do not come from bad icons. They come from good icons used with the wrong meaning. You search for users , pick a clean SVG icon, place it in the sidebar, and move on. Then later you need another icon for: Customers Team members Account owners Permissions Audiences Invited users Admins Suddenly, the same “user” metaphor has to carry too many meanings. That is where SaaS dashboards often start to feel noisy. Not because the icons are ugly. Not because the SVGs are technically wrong. Not because the design system is broken. Because the icon choices were made by keyword instead of meaning. Keyword search is only the first step Most developers choose icons like this: Need an icon for billing? Search billing . Need an icon for users? Search users . Need an icon for analytics? Search chart . Need an icon for settings? Search settings . That works for finding candidates. But it does not solve the real UI problem. A keyword tells you what the icon is related to. It does not tell you what the icon means in your product. For example, search for settings . You might find: A gear Sliders A wrench Control knobs A preferences panel A tune icon They all match the keyword. But they do not say the same thing. A gear usually means global settings. Sliders suggest adjustable preferences or filters. A wrench feels technical or maintenance-oriented. Control knobs suggest fine tuning. A panel icon may suggest a configuration screen. The same keyword can point to different mental models. And in a dashboard, mental models matter more than decorative accuracy. SaaS dashboards are meaning-dense interfaces A marketing website can sometimes get away with decorative icons. A SaaS dashboard cannot. Dashboards are dense. They contain navigation, actions, status indicators, tables, filters, empty states, permissions, billing screens, integrations, reports, and settings. Users do not look at each icon in isolation. They scan. They compare. They move quickly. They expect

Svg/icons 2026-06-18 05:38 13 原文