SOAP is good for flexible APIs due to xml “eats anything”, the “included” support for signatures and schema validation.
53 karma · joined July 29, 2021
be confident that the service is not keeping logs? JÁ!
Also, as you experienced, you can implement new "language restrictions" using zod or new lint rules. Making your project more resilient to version updates and creating your "language superset" that can growth with you.
For example, in a project which generates images I usually set a specific set of pixels.
It’s a return to the old easy times.
However, many times I only use a small subset of it.
I recommend to begin with small steps and increasing the complexity a little bit on each one before being crazy applying ALL for a “to-do” app: pure html, htmz (a tricky way, TAKE A LOOK), htmx and react or whatever.
Finally, I also recommend to follow htmx in Twitter, you will laugh a lot.
Also, my own in-house servers if I don’t need so much availability.
The html + css approach is wonderful, easy to learn and thanks to arias and html standard amazing in terms of accessibility.
I don’t like the windows register and some of its issues derived of retrocompatibility. Also, many of its defaults for directories or “system hidden files”.
And now, you can use AI to be “inspired”
React and others are simply a tool to pass the logic to the client. Useful in situations like apps that can run almost completely without the server or it can manage the offline situations.
All the related tools are only optional things to improve something: • transpilation for older browsers • talwindcss to manage the styles -if you are a lot of people- • redux or others to manage the application state
For other kind of applications, you can continue using the same pattern where the server has the main responsibility of generating the entire view.
In my case, I’m quite happy using htmx and avoiding frontend frameworks because usually I don’t develop offline apps.
For a playground can be excessive, but for production is a nightmare.
Otherwise, you can use only JS with JSDoc and enable the @ts-check.
Or start new projects for your own curiosity. I implemented a cache policy recently and I learned -tried- to develop different parts of an OS.
When you are making some personal software, in general you know how it works, the problem is when you use external tools.
Many times I had errors due to optional params in a constructor to capitalize or not capitalize the keys.
Also, typescript helps you documenting the code “without” documenting, only looking for what types are passed.
A basic ( and not at all! ) approach to know if it is funny for you
The first cause is that in general users use more their phone than their computer.
The second cause is a corollary of the first cause and the existence of tools such as push notifications.
The main cons that you can find are the sync work between teams ( here is the hard work, if you separate in little pieces you can cause that teams need more sync effort ) and devops effort.
Many code is slow due to it has a couple of wrong implementations, such as rendering or make something heavy all the time when you have to do it only one time.
There is no problem to create a decoupled system using di, the final performance it will be tolerable.
Also, you have the possibility to create custom builds with tests and good practices in the main branch.
Sure, it’s the best for the product, but it is stupid pay a sub for something like a calendar. Think if you pay for system tools like file manager, custom configurations…