Hello. Appreciate your question. I think that this is a good use case for the Repository Pattern.

In your case, this might look something like this:

• TicketRepository, ScheduleRepository and TimerRepository interfaces which have their functions like create(), read(), update(), delete(), complexQueryByManyParams() etc. All your domain code should expect and operate on these interfaces.
• FirebaseTicketStore, FirebaseScheduleStore, FirebaseTimerStore classes which implement the respective interfaces. All your logic that relates to Firebase should be encapsulated here.
• You can later safely do things like swap out a FirebaseTicketStore with a MysqlTicketStore

You can consult the Design Patterns / Gang of Four book for more details

Off topic, but personally I don’t feel you should worry too much about having to change the database in the future. I have rarely seen it happen in my career.

2007 - Rob Pike and Ken Thompson think it would be really cool if C was more like Java, and that it would be even more cool if it used the Pascal-style “x := 5” syntax. They lock themselves in a dark room over the winter and create Go. People criticize it for not being more like Rust, despite Rust not having been invented yet.

2009 - After an airplane crash leaves Graydon Hoare stranded in the middle of the Arabian desert, a mysterious camel appears and saves his life. He creates Rust, and adds obtuse syntax and a merciless compiler to mimic the feeling of being stranded in the desert. Masochists worldwide rejoice.

2012 - Anders Hejlsberg discovers some mushrooms growing from the base of his bathtub. After consuming them, he has a revelation that C# needs more Javascript. He invents Typescript. Typescript is a relatively verbose, garbage collected, class based, statically typed, single dispatch, object oriented language with single implementation inheritance and multiple interface inheritance. Microsoft loudly heralds Typescript’s novelty.

Extra fun fact for comment reading friends: This post is the origin of the meme “Monads are just monoids in the category of endofunctors. What’s the problem?” Source

Hear me out, but I believe that using Rust holds Lemmy back.

Writing Rust code is difficult, and fairly time consuming. It’s difficult to get right, and as other commenters have noted, Lemmy code seems to do a lot of things for the “hype factor” (like Websockets). It’s difficult to find enough devs as well.

The article about Discord switching to Rust from Go in the top comment is misleading in my opinion. They totally rearchitected their service while rewriting it, so it’s an apples to oranges comparision.

Caddy is great, I’ve been using it for all greenfield projects.

P. S. Have you checked out the Caddy API?

I’ve heard of SQL Island and SQL Police Department which appear to be in the same vein, but I haven’t got any hands on experience with those two.

You must be a fan of the primeagen

This is really nice! You might also enjoy: Select Star SQL and SQL Murder Mystery

I work on nginx cache modules for a CDN provider.

While websockets can be proxied, they’re impractical to cache. There are no turn key solutions for this that I’m aware of, but an interesting approach might be to build something on top of NChan with some custom logic in ngx_lua.

I agree with you that web proxy cache’s aren’t the silver bullet solution. They need to be part of a more holistic approach, which should start with optimizing the database queries.

Caching with auth is possible, but it’s a whole can of worms that should be a last resort, not a first one.

I came today from Reddit. Think i’m here for good. This feels magical.

Revolution is in the air?

Back in the day, we used to have “post2host” forums, where you could get VPS servers for free just by being active in the forum. That’s where I cut my teeth on Linux!

Without that, 10 years ago, I would not have my career today. I am thankful.

This! Selfhosting your own small apps is the best way to get practical, hands on experience with Linux administration.

This is a good take. All of programming is ultimately just tools to solve a problem, and if we don’t have domain knowledge, we can’t effectively solve the problems that we set out to in the first place.

Really hit the nail on the head about the “invisible decisions” which happen like the quality vs quantity with sails.

I’ve been using ChatGPT at work quite a bit now. Some of the things I’ve used it for are:

1. Writing a shell script that scrapes some information about code modules and shows them neatly
2. Minor automation scripts that setup and make my day to day docker workflow easy
3. Writing random regex, sql, lua pattern matching functions
4. It turned out to be surprisingly good at creating code examples for certain undocumented APIs (kong.cache, kong.worker_events, kong.cluster_events) in Kong API Gateway.
5. Copy pasting a rough python automation script, converting it into Go, and adding it in the application itself.

I still don’t feel comfortable using it for anything big.