Tom Maiaroto

The one they have the easiest time with. They're all designed to do the same thing. They differ in their integrations with other services and such...but GitHub is so ubiquitous that most services can integrate with it. Even AWS as I noticed their Amplify service can also build and deploy straight from GitHub and even do preview build/deployments from branches on pull requests in GitHub.

Only other real concern is budget if one was significantly more expensive for some reason. The first concern is simply finding tools the team is comfortable with and finds valuable enough to use. Nothing worse than buying a bunch of services and tooling that go unused. That's just waste and confusion.

Postgres is a very capable database and it sounds like your application is already designed with relationships in mind. Firestore is not relational and so that's probably why you're having a tough time - your application is just better suited by a relational database and that's ok.

I'd need to know more about your application and it's needs. What was the draw to Firebase? Just that it's a "noSQL" database? Don't let anyone tell you one is better than the other.

Interestingly enough, some people are building an open source project that provides an alternative to Firebase. At least some of its features anyway. It's called supabase. It uses Postgres too. It's a collection of a few modules, one of which is called "realtime" that provides realtime updates via websockets. I'd check that project out because it may provide some of the features you were interested in. Again, I'd need to know more about what your application needs and what you were drawn to with Firebase.

Also bear in mind the convenience of working with Postgres over Firebase. It's a lot more straightforward and you can find many GUI clients or use CLI to make queries and browse data. Yes, there are some for Firestore as well, but not as many. Also, don't forget about query insights if you're using GCP Cloud SQL or if you run your own database instance and install observability tools. Firebase may hide all of this, but you still may one day end up with a performance concern. Even though it's advertised as this infinitely scalable thing. That's not quite true, though it is very scalable, one of the trade offs is limited query features.

Then consider vendor lock-in. If you're really interested in a noSQL database or want a more straightforward one that doesn't include vendor lock-in and limited querying, check out something like MongoDB instead.

I would probably stick with the same tooling depending on how large the code base is. The grass is always greener as they say. The reality is almost all general programming languages can suit the needs of your typically app that just needs to read/write and report on data. You can always pull in various services or build your own with other languages, databases, and tools that are more purpose built if you have the need...though it's usually easier to use that strategy on the web. So if you're talking about desktop software, then we're in a different ballpark. There are other considerations too. If the current code base is so full of tech debt and so confusing, you may want to start fresh. Particularly if it was an app that was built and changed from the very beginning as hindsight is 20/20 and you now know things about how the app needs to work that you didn't know before. Another consideration is cost to maintain and build. If you need additional resources, what's the cost and availability of programmers that can code Java and the Groovy framework or those who can code Node.js (I'd suggest Typescript if starting fresh) and Express. There's really no right or wrong answer here at a high level and you're not doomed for going either way. You just may be able to be more cost effective depending on your situation.

Why do you need to be concerned with database migrations? There's nothing wrong with the modules you chose. Set up the schema manually or bring in a separate module... likely just a go install for a binary that will have a CLI for you to do any db schema creation and migration work you need - outside of your code base.

There's absolutely no reason at all that you need a more feature rich module. If you wanted something that offered a little more try an ORM likely possibly gorm.

I'd honestly just get a database GUI tool (dbeaver is what I use) and create your schema there. How often is your schema going to change? How often will you undo schema changes? Probably not much. I wouldn't worry about a DB migrations solution yet. You likely won't get any value from one. Edumacation though...you could learn about how they work.

I've been using Sentry lately. I've used all of them over the years and they are roughly the same. They're going to give you insight into exceptions being thrown on your JavaScript apps. They also support other languages as well and server side issues. In my opinion the frontend JS app bug monitoring is the primary draw here as there already exists so many backend logging and monitoring tools. In fact, I think these tools are also lagging when it comes to the backend, but they are of course trying to expand their product offering and it makes sense to connect frontend with backend to see an entire request lifecycle. Many of the backend tooling and services actually went the other way around and are lacking for the frontend. No one really seems to have nailed it.

I like sentry lately because they have recently brought online performance monitoring. With that and their current solutions, it's a very powerful and easy to use tool to gain insight on not only bugs to be addressed but also bugs and performance over time - from release to release. So you can track how your releases are having an affect.

If you are already entrenched in one tool, I'm not sure if it's worth switching. It depends on if you had any historical data you wanted to keep and how much work it is to switch. These tools are generally rather effortless to set up. Getting the source maps to Sentry can be a bit of a pain, but once you're set there with a process you don't need to think about it again.

I'd look at SendGrid for bulk and transactional emails. They have a template system where you upload/save templates on their end that you refer to when you use their API. You then pass an object with key/value pairs for replacements in the template. I believe they are handlebars templates. Anyway, you can send in bulk this way.

It will be far cheaper to DIY with AWS SES, but you have to code quite a bit yourself. You may want to look if there's any open source project that helps here. I'm not aware of any, I'd have to Google it.

One downside of SendGrid is that testing things is difficult. They have a "sandbox" that will tell you if the API request is correct, but it's a bit useless. It doesn't let you see if your email looks correct and that the data was replaced correctly. So if as you code and test you're going to be sending real emails. Less than ideal for a QA team. I wish SendGrid had a Mailtrap type feature. Then you can send to any email address you like and just have it land in a fake email bin that you can share with your team. To me, this is a critical feature SendGrid is missing. Other than that, I've been happy with SendGrid. A little pricey I think, but they do a great job retrying to send email, adding emails to a suppression list, etc. Again, all nice features you'd be on the hook for building if you went with something custom with SES. So factor in time savings and SendGrid has great value. Long term and depending on your volume, that may be a different story.

Go is used for the server side code that harvests data, generates reports, and hosts the API for interacting with Social Harvest. It is the major piece of technology used to make Social Harvest possible. Go