I think for starting a startup, a simple LAMP+Framework setup is still the best approach.
For example Debian+Apache+MySql+Python+Django.
Although I would use SQLite these days instead of MySql.
I think for starting a startup, a simple LAMP+Framework setup is still the best approach.
For example Debian+Apache+MySql+Python+Django.
Although I would use SQLite these days instead of MySql.
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.
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
Have any good links for this?
Haha, i have always known it to be PHP
That's why I said "for example".
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)
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.