Yeah, this is really not a good idea unless you have a very specific technical reason for it. Pieter Levels does it for his projects, but I'd focus on taking product/business advice from him instead of technical advice most of the time.
One of SQLite's limitations is only having one write connection to a database at a time. So splitting into multiple different DBs allows you to have multiple write connections. However, for most projects, it's unlikely you'll hit a traffic scale where you would need to do this.
What I would recommend doing this for is when you have app functionality that can be DB-heavy and you don't want to affect your users, like a DB-drive cache or queue system.
If you aren't using a framework yet, I can highly stress that you try one out. And especially if that one is Laravel! If you think base PHP is fast to work with, once you get the hang of the ecosystem, you can go to super speed with Laravel.
If you'd like an example of this multi-SQlite DB pattern, I use it in my #toyboxforlaravel project.
The long and short of the multi-db usage as well is that there's separate databases for Queue, Cache, and Pulse (performance monitoring) functionality, because each of those can become very write-heavy and affect users as app traffic scales up.
This is a really useful info and I really appreciate for this. Thanks my man @nikspyratos
Ive tired rails, I’ve issue with the ORM, has many has one from orm is confusing sometime for me. Means I can understand but when I want to implement something. I actually struggle. Also, I want to add functions by myself and also want to understand how security work properly. And when I want to implement something in php it looks easy.
Also SQLite is easy to setup, jquery is easy to use. Also I can understand php easily.
I just want to know the above thing and then I want to stick. If a website have 1ml visits per month and I have like 15-20dbs. Will it make my website very slow? If not then I’ll just stick to the same stack. :)
You don't have to use the ORM if you don't want to. But that's really like 5% of the framework when we're talking about using frameworks.
Personally ORMs just make things faster to develop with than hand writing queries.
There's also plenty of learning resources online, like Laracasts.
There are projects out there scaling pretty well with just SQLite, there's no reason yours wouldn't. I wouldn't worry about trying to serve 1 million a month yet if you aren't even serving 1. Solve problems as they arise, not before.
If your aim is to learn new things specifically for shipping, then yes.
With only the free packages in the official ecosystem, you can have user registration & auth, payment provider setup (Stripe, Paddle, or LemonSqueezy), application performance monitoring, feature flags, code quality linting, websockets, API setup (both simple and complex like OAuth) and social logins (e.g. Google), all running within a few minutes.
Then there's the free WAMP/XAMP alternative called Herd which makes the dev environment easier.
Then there's the paid ecosystem, which can take care of infrastructure for you (both normal servers with Forge and serverless with Vapor), deployment (Envoyer), have premium payment dashboards (Spark), and application admin panels (Nova, but I prefer the free Filament instead)
Also, currently the plan here is to ship ideas fast as possible. Maybe InshaAllah in future if something turn big. Then I’ll think at that time. Till then I just want to sharp my axe(skills). So I can ship something. :)
Welcome back, and hell yeah welcome to PHP!
Yeah, this is really not a good idea unless you have a very specific technical reason for it. Pieter Levels does it for his projects, but I'd focus on taking product/business advice from him instead of technical advice most of the time.
One of SQLite's limitations is only having one write connection to a database at a time. So splitting into multiple different DBs allows you to have multiple write connections. However, for most projects, it's unlikely you'll hit a traffic scale where you would need to do this.
What I would recommend doing this for is when you have app functionality that can be DB-heavy and you don't want to affect your users, like a DB-drive cache or queue system.
If you aren't using a framework yet, I can highly stress that you try one out. And especially if that one is Laravel! If you think base PHP is fast to work with, once you get the hang of the ecosystem, you can go to super speed with Laravel.
If you'd like an example of this multi-SQlite DB pattern, I use it in my
#toyboxforlaravel project.
Oh and PS to optimise your SQLite DB performance, have a look here:
github.com/nikspyratos/toybox…
All of those are pulled from this and other articles:
kerkour.com/sqlite-for-servers
The long and short of the multi-db usage as well is that there's separate databases for Queue, Cache, and Pulse (performance monitoring) functionality, because each of those can become very write-heavy and affect users as app traffic scales up.
This is a really useful info and I really appreciate for this. Thanks my man @nikspyratos
Ive tired rails, I’ve issue with the ORM, has many has one from orm is confusing sometime for me. Means I can understand but when I want to implement something. I actually struggle. Also, I want to add functions by myself and also want to understand how security work properly. And when I want to implement something in php it looks easy.
Also SQLite is easy to setup, jquery is easy to use. Also I can understand php easily.
I just want to know the above thing and then I want to stick. If a website have 1ml visits per month and I have like 15-20dbs. Will it make my website very slow? If not then I’ll just stick to the same stack. :)
You don't have to use the ORM if you don't want to. But that's really like 5% of the framework when we're talking about using frameworks.
Personally ORMs just make things faster to develop with than hand writing queries.
There's also plenty of learning resources online, like Laracasts.
There are projects out there scaling pretty well with just SQLite, there's no reason yours wouldn't. I wouldn't worry about trying to serve 1 million a month yet if you aren't even serving 1. Solve problems as they arise, not before.
Exactly, that’s why I want to use simple stack. So are you suggesting me to use laraval?
If your aim is to learn new things specifically for shipping, then yes.
With only the free packages in the official ecosystem, you can have user registration & auth, payment provider setup (Stripe, Paddle, or LemonSqueezy), application performance monitoring, feature flags, code quality linting, websockets, API setup (both simple and complex like OAuth) and social logins (e.g. Google), all running within a few minutes.
Then there's the free WAMP/XAMP alternative called Herd which makes the dev environment easier.
Then there's the paid ecosystem, which can take care of infrastructure for you (both normal servers with Forge and serverless with Vapor), deployment (Envoyer), have premium payment dashboards (Spark), and application admin panels (Nova, but I prefer the free Filament instead)
Also, currently the plan here is to ship ideas fast as possible. Maybe InshaAllah in future if something turn big. Then I’ll think at that time. Till then I just want to sharp my axe(skills). So I can ship something. :)