Define 'learn' - to what depths? Learn databases next to grep/sed etc. Cringe.
All the trendy crap you likely won't need: mongo/influx/firebase/cassandra/redis - learn it if you need to. Hopefully some of these will be untrendy pretty soon, then forgotten.
This is bad and it's not credible to learn all this to a useful level. This is laughable. I hope starters here aren't put off by this.
For company-internal webapps, we found that Postgres and Postgraphile [1] usually replaces the need for any other backend. You can do a lot with SQL and database functions. If you're worried that the application is coupled too tightly to the database, create another database schema just with views and functions as an abstraction layer. If something can't be done in a Postgres stored procedure, like rendering graphics as SVG or PNG image, use the python language just in this stored procedure.
The postgres+postgraphile combination is really powerful! We used to build GraphQL backends with Python and Ariadne before.
I should say that the applications are largely for read-only data access. We define not null, unique etc. database constraints to ensure data problems are detected during import. An application for data entry used stored procedures as GraphQL mutations where more complex logic for data validation was required. So one parameterized procedure can check its inputs and update multiple tables in one transaction, or raise an error if the validation failed.
We also used postgres policies for row-level access control in one application. The policy functions could rely on the logged in user being already validated and present in a SQL variable (we set that variable in a postgraphile javascript hook).
The database schema and stored procedures are just one or multiple SQL files which are in version control. I also commit example GraphQL queries, which indicate how a schema can be used and can serve as a manual test case.
I don't agree with the flagging - it's clearly a "mindmap" style guide for everything say an intern should expect to read up on / try out. I think it would be a useful basis for intern / junior training when you have nothing else.
Of course it's not possible to learn all of this as a junior to some "deep" level - but it's a syllabus - and you would not want to take on this as a junior without someone around to guide you.
This is interesting. there are lots of tech there you learn while at work. I haven't touched Cassandra, Couch, Kafka, etc. This list will literally scare any beginner, stress any mid-level individual (Am I missing something?), and make seniors laugh.
I think a better list will be something of a specialized path made by devs and engineers working right now.
We can go even further by dividing the path by field (fintech, adtech, streaming services, retail, etc...).
There is nothing about rendering either JSON or HTML or fragments in websocket based systems. That's the interface to frontend or maybe we could even call it server based frontend (traditional HTML pages) but as long as it uses CPU cycles in the backend server and it's part of the backend app shouldn't it be in the backend roadmap?
I did for one project, although I got kicked off a year in, because they didn't know what they had.
IMHO every REST API should be discoverable this way like the web, for example with links to related resources in responses (at least in dev) and by having OpenAPI documentation at a root path like / or /api.
JSON API provides much of this for free when used with something like Laravel:
How does one consume this road map? Any effective strategy here to use?
I'm not questioning usefulness of this, but how to make use of it to become a better developer? Binge read from top to bottom on topics not having familiarity in it?
So.. you are shipping and iterating… while others are pulling together their stack?
For those new to backend - I’m assuming you’re more referring to the simplicity of choices vs the actual technologies, as several could be interchanged.
For a startup it should be whatever you know and are familiar with, and preferably something managed. For $20/month you can run a mysql database, plus a DO app platform app which is a docker container with whatever stack you want. A single tutorial will give you a CI CD pipeline with reproducible artifacts and something that will scale until it's worth actually paying attention to it.
DO app platform is rather new. It will probably be in flux for the forseeable future. And then you have to dabble with changes. With barebones LAMP you can be a happy camper.
Its 2 and a half years old. I've had a side project (just a crude app) deployed with this and GitHub actions for a year, and in that time I've not once had to change anything on the DO side.
I can set up a CI pipeline that deploys to a DO app service in under 5 minutes and not have to touch it again for a long time.
If DO decides to pull the rug on supporting containers then I'll use some other similar platform, and in the unlikely scenario that all of those providerd disappear, ill spin up a VPS on whatever provider you run your custom lamp stack on, install docker and move on. Until that day comes, I won't worry about the underlying platform and I'll continue to deploy using a zero friction pipeline that I set up when I waited for my coffee to brew one morning last January
Agreed. I would recommend learning many concepts, e.g. in the database section, what's the difference between a document/time-series/column/graph/etc. database. A broad knowledge of such things makes us better at choosing the right tool for the job, rather than (poorly) re-inventing stuff that already exists.
However, I wouldn't bother choosing any actual implementation, for a few reasons:
- It takes time that could otherwise be spent learning something else
- If you're inheriting a legacy project, that choice has already been made for you
- If you need to choose one for some green-field project, the landscape/tradeoffs may have changed since you originally learned this stuff (e.g. your preferred tool may have been discontinued, or some alternative has solved a bunch of its problems, etc.)
When it comes to actually building stuff, start small and simple (e.g. LAMP, (Fast)CGI, etc.); whilst keeping those concepts in mind to avoid limiting future options (don't over-abstract, since YAGNI; but likewise don't paint yourself into a corner)
Not as of a couple years ago. Frontend is too primitive to move as quickly as Next.js. There’s a reason 2/3 of significant new web projects coming out, I view-source and it’s Next.
Guilty as charged, hehe. Where I work it was decided that we rewrite all our platforms. We decided going with Next.js and We couldn't be happier.
We don't care about lit, qwik, solid, or any other framework for that matter. I mean, we know they are there but there are much to cover and the team is already comfortable using Next. API routes are good too for business logic pertaining the app itself.
For our backend, we stayed with TS, Node.js, and the good ol' Express.js.
Define 'learn' - to what depths? Learn databases next to grep/sed etc. Cringe.
All the trendy crap you likely won't need: mongo/influx/firebase/cassandra/redis - learn it if you need to. Hopefully some of these will be untrendy pretty soon, then forgotten.
This is bad and it's not credible to learn all this to a useful level. This is laughable. I hope starters here aren't put off by this.