I'm on Remix / Drizzle ORM / Render.com / Render Postgres / Cloudflare R2 / DaisyUI + shadcn/ui these days.
Drizzle can be a bit tricky if you're coming from ActiveRecord but once you have your own helpers with a base class that implements common method such as find_by({ key: value}) / create({ data }) / update(id, { data }) / delete(id), things get better.
Render is really good - you don't need any specific configs, just set env vars on their dashboard and git push to deploy. Simpler and better than Heroku workflow.
If you EXPLAIN that query, it's a DEPENDENT SUBQUERY which has to fetch N*M records. It would be mitigated if the columns are property indexed, but two separate queries (N+M) just as eager loading would be faster and more predictable than nested scans in terms of IOPS.
Thank you. I think you made a good point - by not charging I may be actually making people skeptical. We even have a vibrant developer community on bots and extensions, but it's barely known (shit, I realized that it's not even mentioned on the top page). I'll have to come up with some turnaround ideas.
As a founder of http://lingr.com, I know firsthand how hard to build a chat app and make it sustainable. I've been working on it since 2006, first as a startup, then as my personal side project.
I've learned to not invest too much on the project, staying with the minimum server cost, and that's the only sustainable way for me. In fact it costs me almost nothing and users have built trust on me for running it for 6 years.
I'd give her tons of credit for trying to turn it into a real business. That's what I've been failing so far, or maybe I just don't even have the guts to do. I admire her courage and thus feel really sorry.
Validate if he/she's a good fit for your team first. Usually it takes time. Equity has a permanent effect and you don't want to make a decision in haste.
As to MongoDB, in case you only have two members in a replica set, you add an arbiter, not strictly three members.
An arbiter is indeed a lightweight mongod process that doesn't have storage, and should be added to break the tie when you have even number of members. I like the MongoDB's design, and it is probably optimal for 99% of use cases.
There are three key concepts: Split-brain, Quorum, and Fencing. I find this article fascinating.
For instance, up until 2012 introduced with Ivy Bridge, a true hardware-based random number generator hasn't been available to the masses. (http://en.wikipedia.org/wiki/RdRand)
what we believe to be random may not be, and I've seen UUIDs generated on cheap mobile devices can easily collide when their clock battery is dead.
I'm on Remix / Drizzle ORM / Render.com / Render Postgres / Cloudflare R2 / DaisyUI + shadcn/ui these days.
Drizzle can be a bit tricky if you're coming from ActiveRecord but once you have your own helpers with a base class that implements common method such as find_by({ key: value}) / create({ data }) / update(id, { data }) / delete(id), things get better.
Render is really good - you don't need any specific configs, just set env vars on their dashboard and git push to deploy. Simpler and better than Heroku workflow.
You can take a look at https://github.com/remix-run/blues-stack to learn how you'd manually implement cookie-based auth on this framework.
Remix is the closest thing to Rails in the JS ecosystem IMO