4 ms·

PocketBase + Go + HTMX

razemio 3y ago
Pocketbase is just superb. I am using pocketbase together with scalajs and svelte. It saved me so much time setting up the basics and you won't regret it once the project grows. Anything works with pocketbase but go or any js based stack has an easy onboarding.
- joshlemer 3y ago
  Do you eventually have to move off pocketbase? Looks like it only supports SQLite, and therefor obviously can only run a single server instance. How do you plan to migrate off it in the case that you have higher availability or traffic needs?
  - joking 3y ago
    use a bigger server until the revenue is big enough to justify the migration.
  - razemio 3y ago
    Here are some suggestions if you ever need to scale. https://github.com/pocketbase/pocketbase/discussions/395 https://github.com/pocketbase/pocketbase/discussions/395 Never happened to me. SQLite is faster than most people think. When you hit the limits of sqlite, chances are high that you can afford to use one of the scaling solutions mentioned above. Here are some benchmarks: https://github.com/pocketbase/benchmarks?tab=readme-ov-file https://github.com/pocketbase/benchmarks?tab=readme-ov-file
    - joshlemer 3y ago
      Thanks, but here I'm thinking more about availability than anything else. One single instance of a service doesn't seem great
begueradj 3y ago
PocketBase is not ready to be used for production yet
- yoyohello13 3y ago
  Unless you are very lucky, odds are your app is never going to be hitting "production" workloads. If it ever does, then you can pivot to something else (and by that point you'll presumably have the revenue to do so).
isaacsultan 3y ago
I'm interested in checking out Go. Could you recommend a stack please? * Testing - test runner, mocking * Database - Typesafe queries, ideally as little abstraction as possible, migrations * Web app framework * Dependency injections (or do you prefer doing it manually over using a library)
0xblinq 3y ago
LOL. The HTMX hype is worse than every other fashionable framework. Only backend developers like it. As soon as you have to do anything minimally complex it's just terrible.
- yoyohello13 3y ago
  Yeah, much easier to setup an entire build pipeline with 1,000 NPM dependencies to render a form.
  - 0xblinq 3y ago
    If all you have to do is render a form you don't even need HTMX. IF your project is just about rendering forms then fine.
- recursivedoubts 3y ago
  oh, idk https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
  - 0xblinq 3y ago
    From what I can see from the demo that's a super simple application. It might make sense to use a tool such as htmx/unpoly/hotwire/etc. What I don't get is people just blindly "following the hype" (as with anything else) and assuming it's a replacement for client side frameworks (react, vue, etc) for anything you might need out there. You already said this several times in some Podcasts I listen to, so I don't blame you. But people are just "hey bro just use HTMX and Go and done". And that might be fine if you're a backend developer that doesn't like JavaScript and have a very simple use case and probably don't have high UX standards or picky designers chasing you with every animation, loading state or performance issue. There are many projects out there with pretty complex UX logic where this will just not work, and if it works the end result is going to be much harder to maintain. Let's not take into account finding people willing to work with these tools (already happened to us where we had to move a Rails/Hotwire project to Rails/Inertia) because no one could work on the frontend, initially created by a backend dev and that became such a mess not even him could maintain it anymore). But again, it is not the technology to blame (it's great!), it is the usage of it. And people can misuse anything, as they misuse react/vue/etc when they're building just a landing page.

Pocketbase is just superb. I am using pocketbase together with scalajs and svelte. It saved me so much time setting up the basics and you won't regret it once the project grows. Anything works with pocketbase but go or any js based stack has an easy onboarding.

joshlemer 3y ago
Do you eventually have to move off pocketbase? Looks like it only supports SQLite, and therefor obviously can only run a single server instance. How do you plan to migrate off it in the case that you have higher availability or traffic needs?
- joking 3y ago
  use a bigger server until the revenue is big enough to justify the migration.
- razemio 3y ago
  Here are some suggestions if you ever need to scale. https://github.com/pocketbase/pocketbase/discussions/395 https://github.com/pocketbase/pocketbase/discussions/395 Never happened to me. SQLite is faster than most people think. When you hit the limits of sqlite, chances are high that you can afford to use one of the scaling solutions mentioned above. Here are some benchmarks: https://github.com/pocketbase/benchmarks?tab=readme-ov-file https://github.com/pocketbase/benchmarks?tab=readme-ov-file
  - joshlemer 3y ago
    Thanks, but here I'm thinking more about availability than anything else. One single instance of a service doesn't seem great

begueradj 3y ago

PocketBase is not ready to be used for production yet

yoyohello13 3y ago
Unless you are very lucky, odds are your app is never going to be hitting "production" workloads. If it ever does, then you can pivot to something else (and by that point you'll presumably have the revenue to do so).

isaacsultan 3y ago

I'm interested in checking out Go. Could you recommend a stack please? * Testing - test runner, mocking * Database - Typesafe queries, ideally as little abstraction as possible, migrations * Web app framework * Dependency injections (or do you prefer doing it manually over using a library)

0xblinq 3y ago

LOL. The HTMX hype is worse than every other fashionable framework. Only backend developers like it. As soon as you have to do anything minimally complex it's just terrible.

yoyohello13 3y ago
Yeah, much easier to setup an entire build pipeline with 1,000 NPM dependencies to render a form.
- 0xblinq 3y ago
  If all you have to do is render a form you don't even need HTMX. IF your project is just about rendering forms then fine.
recursivedoubts 3y ago
oh, idk https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/
- 0xblinq 3y ago
  From what I can see from the demo that's a super simple application. It might make sense to use a tool such as htmx/unpoly/hotwire/etc. What I don't get is people just blindly "following the hype" (as with anything else) and assuming it's a replacement for client side frameworks (react, vue, etc) for anything you might need out there. You already said this several times in some Podcasts I listen to, so I don't blame you. But people are just "hey bro just use HTMX and Go and done". And that might be fine if you're a backend developer that doesn't like JavaScript and have a very simple use case and probably don't have high UX standards or picky designers chasing you with every animation, loading state or performance issue. There are many projects out there with pretty complex UX logic where this will just not work, and if it works the end result is going to be much harder to maintain. Let's not take into account finding people willing to work with these tools (already happened to us where we had to move a Rails/Hotwire project to Rails/Inertia) because no one could work on the frontend, initially created by a backend dev and that became such a mess not even him could maintain it anymore). But again, it is not the technology to blame (it's great!), it is the usage of it. And people can misuse anything, as they misuse react/vue/etc when they're building just a landing page.