Their MIT license is gorgeous. Thx for the video. As for manipulating data at backend you might like clojure. Clojure data structures can be perceived as a ORM, clojure is Data oriented language. You can leverage the java knowledge you already have and be more practical (much more) with data applications.
Thank you for your suggestion! I am one of those guys easily intimidated by Lisp inspired languages 😅. I was actually not that happy with Java in recent years, so I fully switched to Kotlin since Spring offers first class support for it. I'm sure learning Clojure is useful for any developer, I'll have to apply myself and get passed my lips prejudgments
PocketBase's decision to use SQLite made me rethink my decisions because typically you wouldn't need a sharded, replicated DB for small applications or simple SME softwares of course this is subjective to use-cases but it does make you think
I'm new to programming and it frustrates me to see so many solutions for things that may be the same in principle. I just want to learn to program and this video just came to me. I am undecided whether to go for a front-end course with javascript and react or choose back-end with java and spring boots. I just want a little illumination to my mind with the aim of building good things in the future
Hey, @edgarjtribaldo4984! I'll start by saying that it's normal to feel overwhelmed - we all do (check out my dev story, and it'll make more sense - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ntzuRtFZ8KM.html). Here is the path I'm suggesting for people starting on the dev journey. 1. Know your algorithms (things like sorting, recursion, backtracking, dynamic programming and others). If you attended a computer science oriented highschool or university the chances are you already know these. I know, people will say you'll never use them in real world, but going through the learning process you will get used to thinking in a "programming" way. This should take you between 3 to 6 months . 2. Learn a proper programming language that you can use to build scalable backend solutions. Thing here of things such as Java, C#, Python, Rust or Elixir. My advice is to go with Java, because you can easily expand your knowledge with associated programming languages such as Scala, Kotlin or Groovy, and it'll be very easy for you to find a job. Of course, you would need a framework on top of all these, and I suggest you go with Spring. You'll probably need around 1.5 to 2 years to have a good understanding of such a build. 3. Learn JavaScript, Typescript and a UI Library - I suggest React because of its popularity and 3rd party support. On top of that, you can use React Native or Ionic to build mobile apps using the knowledge you already gained. Again, you'd probably need 1 year to have a good understanding of a React + Typescript app. I hope this helps! There is a wide range of free studying material for all the things I mentioned before. I also pointed out the time needed to get a good understanding of all these, because I wanted to make it clear it is a long process, and you need to stick with it! Good luck!
@@aoaxe C# is also a great language to work with. It is actually more versatile than Java, and the .NET framework covers web, mobile, cloud and microservices. If you got the chance, I would actually argue it's better to start with C# instead of Java these days.
Cool video, was pleasantly surprised to see Spring Boot talked about. With the rise in popularity of BAAS solutions I never see anyone mention my two biggest gripes with them. The biggest being, how do they allow you to extend them with business logic? For most apps you're likely going to need a a dedicated backend at some point anyway when your use case grows beyond simple CRUD. This then flows onto my next point which is needing to use a client specific SDK for whichever service you choose. It creates more vendor lock-in / makes changing services later on more difficult and means you'll have conflicting ways of doing things when you inevitably create that dedicated server for business logic.
@ryanfield8592 yep, I agree - there is no standard or abstraction allowing you to switch between vendors. Not for now at least... You might be able to work around the issues with the business logic by: 1. using edge functions; 2. moving some of the logic to the "client". This sounds bad at first, but if you use a meta-framework such as NextJS or Svelte Kit you'd actually be in a node js environment where you can add your logic, and then call the vendor APIs with little impact on performance in the browser.
@@awesome-coding Yeah personally I come from a Java background so I tend to avoid using Javascript for backend stuff. This combined with me being heavily biased towards Angular means I don't really have the option to use all these hot new meta frameworks. I think of all the BaaS I've seen NHost comes the closes to solving all of the problems I have - mostly just because it uses Hasura under the hood. This means a consistent industry standard GraphQL api for everything rather than a client specific SDK. Hasura also has fantastic support for adding business logic to your endpoints. I have project I'm working on with Hasura + Spring Boot that aims to provide the same use case as a BaaS and solve the problems I mentioned while also being easier for frontend devs to use.
Pocketbase is open source and quite extensible with a hook system, I see no problem in that. Client specific SDKs are an option, not a must-have, afterall Pocketbase just exposes CRUD rest API, which is accessible from any platform. I do have my own worries about such out-of-the-box solutions, the only issue I see for now is the lack of control over code structure, which puts project at risk with worsening maintainability over time, but for that we shall see.
@@ryanfield8592 It's nice to see another fellow Java developer here! I also started working in Java, and, for quite a while it was my preferred, primary language. (Back then I thought JavaScript was a terrible mess). However, I gradually switched to Kotlin (especially since it got Spring first class support), and slowly I started to realise that, while great, Java is a bit too conservative and rigid for my taste. So, for any larger project, in my team we go with Spring Boot + Kotlin + OpenAPI (Swagger) for REST APIs (We are considering adopting GraphQL more, but that's a long process..) Getting back to BaaS, it all depends on the company and the projects you are working in. I was lucky enough to be given a lot of flexibility, and be involved in various smaller projects / startup attempts where speed was of the essence. In such cases an isomorphic code approach, where you write javascript once, and you are targeting both the frontend and the backend is very appealing. So, it all boils down to the type of product you are building I believe. Thank you for mentioning NHost, I was not aware of it, and looks pretty interesting!
@@sealoftime you are right! So, if you use Pocketbase for prototyping / beta version, it might make sense to use the REST API directly to make things easier in the future, when you'd need a different backend solution. Using the SDK is so convenient though 😅
@multivitamin7 you are right. I didn't get the chance to look into AppWrite in detail, but it looks more complete than Pocketbase. On the other hand, you'll have quite a few docker instances running on your machine to have AppWrite running. The appeal of Pocketbase is its simplicity and portability, and I'm sure its feature set will grow moving forward.
excellent excellent channel with mind blowing content XD I was able to setup and get started with my long thought out personal project using the knowledge from these videos :D Thankyou for sharing and keep posting such amaxing content. instant sub, Cheers !!!
@@awesome-coding Keep it up ! and thankyou for sharing. I would like to ask if it is possible to do auth based routing using astrojs alone in SSR mode ? My use-case requires some protected pages and I am not able to find enough documentation on how to do auth based routing with astro super thanks in advance
If a startup wants to quickly get started with all of Firebase's capabilities and benefits, can Pocketbase+Fly truly eliminate the requirement for Firebase? Honestly?
Hey! This is a good question. So they both offer the basic storage / auth and other core needs you'll have in a backend service. I just started working on a new product, and the team behind it still decided to go with Firebase instead of Supabase or Pocketbase. What I really like about Pocketbase is its REST interface, so it is going to be extremely easy to switch to a more mature framework if you startup really grows in size. A lot of times it feels like Firebase will lock you in because of their APIs. One downside is that Pocketbase still has a long way to go to get to a stable v1 release. All in all, if your team is larger, and you are working on a serios project backed by investors or actual customers I wouldn't risk it with Pocketbase at this particular time. If it's a smaller endeavour, and you can afford the risk of using a beta product, I'd go with pocketbase since it is open source, reliable, extendable, and easier to replace if needed.
@@awesome-coding That's right, let Pocketbase get to v1.0 and grow up. On top of that, it's hard for me to work with Fly because I don't like dealing with a lot of k8s. Although Firebase has everything else, I despise the fact that its Firestore db is proprietary. So, I have finally decided to use Vercel for the frontend + Supabase for the backend and database. Plus their pricing is quite generous for starting up.
@rewrose2838 I'm guessing that the Firebase issue is caused by them being backed by Google? If that's the case, take a look at Supabase as well. It is built on top of open source tools, and it seems pretty powerful. I don't think that their pricing model for cloud hosting is realistic, and they'll probably increase the subscriptions in the future, but you can also self host their stuff.
one thing you didn't cover is pocket base is designed to be used as a framework. you have direct access to the echo router and can add what ever you like to it
Yes, you are right about that! The way I see it, if your app really gets to a point where it needs horizontal scaling, Pocketbase might not be for you.
horizontal scaling is tricky even with regular sql databases there's a bunch of sqlite replication tools out there but still if you need somethin that'll scale like that just start off with postgres or surrealdb and a perfomant language like GO or even better rust RUST
Hey! All that code is "frontend", meaning react or whatever other lib you are using. With PocketBase and the SDK you have no code running on the backend. Everything runs in the browser, and interacts with the backend REST API PocketbBase is exposing.
I know this video was made 11 months ago but doesn’t anyone 😢know how to access an already configured pocketbase with existing data which the author has given you full access to because I remember I typed ./pocketbase serve and when I tried to click on the link I got a code 404 error . I never got this code when I was working with my own pocketbase
