Readit NewsI ask because I'm wondering if I should care about docker in the beginning of my project which will have very few concurrent users/requests and would run fine on a single machine.
EDIT: Thank you to all the kind answers!
When I'm working on one service, I often depend on a few other services too. I usually need a storage layer, perhaps API calls to related services, it may even to talk some Amazon services like S3 or SQS. Having a simple way to spin up every dependency locally, even AWS (lots of great AWS API compatible images out there) is really useful if only for local development.
Its also a bit nicer in that React tends to follow ES standards like ES6 classes for components, instead of exporting a POJO for your component. In vue you often have to use function() instead of fat arrow syntax because of the context of "this". With react you used to have lots of .bind(this) boilerplate, but now we have shorthand property syntax. Vue also mixes props & state, where as React keeps them separate. React implements certain lifecycle methods like componentShouldUpdate() whereas Vue doesn't because the creator thinks it would complicate the API, meanwhile there's known issues like between Vue.js & HTML5 content editable due to this lack of lifecycle method.
Vue is easier to get going & much faster to develop in initially, lower learning curve, and friendlier API.
Their documentation[2] wasn't great. It was out of date (missing component attributes, icons etc.) and lacked good examples. Often I would have to dig into the source to figure out obscure errors. When I first starting using @shoutem/ui, I couldn't use the latest version of React Native because they locked themselves into an experimental feature[3] which even until now, seems like it hasn't properly resolved.
Again. I can't comment on their platform but I didn't have a good time using their UI library. Had I known this, I would have just gone with NativeBase[4].
[1] - https://github.com/shoutem/ui
[2] - https://shoutem.github.io/docs/ui-toolkit/components/typogra...
[3] - https://github.com/shoutem/ui/issues/241
[4] - https://nativebase.io/
I feel like I see many projects like this with the goal of transforming data or making more requests and things after each request (redux-saga).
If you have control over the api you are interacting with, most of these things aren’t needed. Plus, less work done on the client the better, right?
We had a backend and frontend team, both working on the same product but the two teams disagreed a lot and would take weeks to make a small change even if it wasn't a breaking change.
To add to it all, there wasn't a standard to deprecating APIs so even a simple key rename could cause everything to blow up. Things weren't fun so I can see the need for these kinds of tools.
I use flyway now for db migrations and what's great is that I can perform migrations in multiple steps (because it's just SQL). So in this case, I can alter table and add a column with nullable, deploy my app to write to both, migrate data at a later time, deploy app again to stop writing to the old column, update column constraints and remove old column.
Does Django ORM have this kind of flexibility?
https://news.airbnb.com/airbnbs-design-to-live-and-work-anyw...