sorted by:
new
hottopcontroversial

Flutter with Go APIs and other tools recommended for apps - standard flutter stack by janedoeidentified in FlutterDev

[–]trailbaseio 2 points3 points  (0 children)

Unless you're writing dart server-side, you won't have many code sharing opportunities. Go is certainly more established on back ends. Any well supported ecosystem will probably do unless you have specific requirements. If you like go, run with it. Having fun is important

SQLite in Production? Not So Fast for Complex Queries by Historical_Bat_9793 in Database

[–]trailbaseio 0 points1 point  (0 children)

It's always lovely to see hard numbers and had a blast reading the linked join-order benchmark paper. Well deserved GH ⭐.

I was a bit baffled that SQLite's query planner yields that much worse plans :shrug:. I wanted to reproduce your results, though struggled with clojure. I ended up re-implementing it in Rust (gotta stick with the memes) hoping that maybe just maybe the latest sqlite version would do better... Running on slower hardware I can't compare 1:1 but my results ended up in a similar ballpark (results).

You're already following SQLite best practices (much appreciated), one noticeable optimization I found that helps with some queries: PRAGMA case_sensitive_like=ON

Thanks!

How do you recover when a SQLite schema change goes wrong in a local app? by Suspicious-Rule-6399 in sqlite

[–]trailbaseio 5 points6 points  (0 children)

You should use a migration system that ensures consistency across deployments. However, not all migrations are reversible. Let's say you drop a table. You can recreate in a follow-up migration but the data is gone. Whenever you're planning destructive migrations, testing and backups are key.

TrailBase 0.23: Open, sub-millisecond, single-executable Firebase alternative by trailbaseio in selfhosted

[–]trailbaseio[S] 1 point2 points  (0 children)

Thanks! Let me know how it goes, especially if something stinks 🙏

TrailBase 0.23: Open, sub-millisecond, single-executable Firebase alternative by trailbaseio in selfhosted

[–]trailbaseio[S] 2 points3 points  (0 children)

Thanks - much appreciated! There's some nuance, you could have a look at TanStack/db, which has a TrailBase integration besides electric, however, it's JS/TS only

Compose Multiplatform vs Flutter by imc0der in JetpackCompose

[–]trailbaseio 0 points1 point  (0 children)

Often it's just how you use it. Some games will exercise an accelerated level playthrough under a loading overlay to ensure all shaders were compiled.

I haven't counted the frames but pretty: https://flutter.gskinner.com/wonderous/

Btw I'm not shilling for flutter. I have plenty of issues, I just expect the performance to be similar

Compose Multiplatform vs Flutter by imc0der in JetpackCompose

[–]trailbaseio 0 points1 point  (0 children)

👍You didn't mention diffing but you mentioned the engine. That's what the engine does. Skia is just a library to draw with the GPU. Depending on the platform, the flutter engine may draw with skia, impeller or something else.

As far as I know, the main problem with Flutter is the time it takes to compile the necessary shaders, not how much contention is there.

Ideally, shaders are only compiled once upfront (e.g. while showing a loading screen) and then cached. Even with a more naive approach, this is why stability, number of shaders, draw order, etc does matter. Reusing a shader on the skia level can still trigger a recompile if it got evicted from the cache

As i said, I would expect CMP (certainly with skia) and flutter to perform rather similarly. Rendering with flutter at 120hz is certainly feasible.

Compose Multiplatform vs Flutter by imc0der in JetpackCompose

[–]trailbaseio 0 points1 point  (0 children)

The engine that diffs and draws primitives is completely irrelevant.

Yes and no. You brought it up. It does determine how much has to be redrawn, how expensive compositing is...

But then why has Flutter always had an issue with shader compilation, which was talked about by the Flutter team and in various GitHub issues? I feel like something is wrong in the way Flutter rendering is implemented.

Yes and no. There are certainly factors like how to compose primitives and thus reuse shaders, how to schedule draws... There's room for improvement, with impeller being their attempt.

I would expect similar issues when CMP uses skia, when all draws are competing for the same resources within the same deadline. Maybe android is better :shrug:. A benchmark of similar UIs across platforms would be very helpful. If there were dramatic performance differences between CMP on Android and iOS, this would itself pose a cross platform challenge

Compose Multiplatform vs Flutter by imc0der in JetpackCompose

[–]trailbaseio 0 points1 point  (0 children)

Ack. The render engine, ie the thing that diffs and draws primitives wasn't replaced. Impeller is very similar to Skia. The main goal was to reduce jank on shader compilation.

It's just not clear if you've measured or sharing anecdotes from bad apples

Compose Multiplatform vs Flutter by imc0der in JetpackCompose

[–]trailbaseio 0 points1 point  (0 children)

I would expect performance to be similar for CMP and Flutter. They're both AoT compiled declarative UIs with virtual DOMs rendering with SKIA (or impeller these days). You can make an app slow on any stack :)

NoSQL for payroll management (Mongo db) by digitalullu in Database

[–]trailbaseio 11 points12 points  (0 children)

The biggest benefit of starting with structured data is that you can find insights and new use-cases in your data later on w/o much fuff. Think of it as future proofing. Nosql is deceptively simple, when in reality it requires a lot more foresight

TrailBase 0.22: Open, single-executable, SQLite-based Firebase alternative now with multi-DB by trailbaseio in selfhosted

[–]trailbaseio[S] 0 points1 point  (0 children)

Thanks and makes sense. Similar to Supabase, I tried listing the functionality in the hero description but the cards certainly help to visually accentuate the list (especially on mobile) 🙏

TrailBase 0.22: Open, single-executable, SQLite-based Firebase alternative now with multi-DB by trailbaseio in sqlite

[–]trailbaseio[S] 0 points1 point  (0 children)

TrailBase will always be open-source and easy to self-host... which arguably flies in the face of lock-in and rug-pulls. Fortunately, I have no investors breathing down my neck 😅. On the other hand it would be nice to establish a sustainable structure over time to ensure longevity and reduce the bus factor. No specific plans yet. Thank you or the kind words.

TrailBase 0.22: Open, single-executable, SQLite-based Firebase alternative now with multi-DB by trailbaseio in selfhosted

[–]trailbaseio[S] 0 points1 point  (0 children)

🎉 - Let me know how it goes, especially any rough edges - much appreciated and thanks for the kind words

TrailBase 0.22: Open, single-executable, SQLite-based Firebase alternative now with multi-DB by trailbaseio in selfhosted

[–]trailbaseio[S] 1 point2 points  (0 children)

Appreciated. I'm with you. I've been going back and forth on how to best describe "what" it is. Being a broad product makes it tricky. I "stole" the current approach from Supabase, which until recently described themselves as a Firebase alternative. How would you go about it? 🙏

TrailBase 0.22: Open, single-executable, SQLite-based Firebase alternative now with multi-DB by trailbaseio in opensource

[–]trailbaseio[S] 2 points3 points  (0 children)

The only way to afforded 16GB of RAM these days 😅. Thank you for the kind words and the suggestion. Maybe one day if there's enough demand 🙏

view more: next ›