emailengine VS good_job

When I started with https://emailengine.app, a similar product, I also considered releasing it as a SaaS. But looking at the competition, it seemed too complicated for me (just look at the compliance list for Nylas Email API https://www.nylas.com/security/#compliance ). Will be interesting to see how it works out for you. Good luck!

EmailEngine has all the code public [1], even though it is not open-source but is source-available. Some core parts I even published under the MIT license, like the IMAP client library I built from scratch to serve the special requirements EmailEngine has for IMAP access [2]

My thinking has always been that those who try to hack the license validation stuff and replace the missing build pipeline were never going to be my customers in the first place, so every second I would spend on them is a wasted effort.

[1] https://github.com/postalsys/emailengine

https://github.com/postalsys/emailengine

Seems open-source to me.

Well, I for one, hope that email stays as complicated as described in the post. Otherwise my project that simplifies access to email accounts (https://emailengine.app) would get no traction :D

I'd like to know if anyone here can share some experience using https://emailengine.app in a larger environment, e.g. managing / watching 100-200 email accounts and processing ~50.000-100.000 mails per day?

I had the same issues when I started with https://emailengine.app - just like Ghost, it’s an app written in Nodejs. I tried multiple distribution options at first and finally went with complete self containment. All modules are pre-installed during the publishing step and thus the user never needs to run npm. Or if you download the “compiled” single binary version you don’t even need node as it’s bundled with the binary (I use the pkg module to bundle these executables). So upgrading is just downloading and replacing the old version files with new ones.

The dowside - no sane way to use compiled dependencies, everything has to be vanilla javascript.

This is the most direct competitor of good_job in my opinion.

Once we are done with default gems, should we look into something we usually use? That's jwt because we need session tokens for our API. Next comes our one and only sidekiq. For a long period of time it was the best in town solution for background jobs. Now we could also consider solid_queue or good_job. In development and testing groups we need rspec-rails, factory_bot_rails and ffaker. Dealing with money? Start doing it properly from the beginning! Do not forget to install money-rails. Once everything is added to the Gemfile do not forget to trigger bundle install.

In the world of Ruby, GoodJob [0] has been doing a _good job_ so far.

[0] - https://github.com/bensheldon/good_job

For Rails apps, you can do this using the ActiveJob interface via

https://github.com/bensheldon/good_job

Had it in production for about a quarter and it’s worked well.

Idk about pgagent but any table is a resilient queue with the multiple locks available in pg along with some SELECT pg_advisory_lock or SELECT FOR UPDATE queries, and/or LISTEN/NOTIFY.

Several bg job libs are built around native locking functionality

> Relies upon Postgres integrity, session-level Advisory Locks to provide run-once safety and stay within the limits of schema.rb, and LISTEN/NOTIFY to reduce queuing latency.

https://github.com/bensheldon/good_job

> |> lock("FOR UPDATE SKIP LOCKED")

https://github.com/sorentwo/oban/blob/8acfe4dcfb3e55bbf233aa...

The suggestion from /u/tofus is a good one. If you are already using redis as your ActionCable adapter I would use sidekiq. If not and you're using postgres I would consider https://github.com/bensheldon/good_job

Probably worth mentioning that aside from delayed_job there are at least two more modern alternatives backed by the DB: Que and good_job.

Good article. Sidekiq is a good, well respected too. However if you are starting out I would recommend not using it, and instead choosing a DB based queue system. We have great success with que, but there are others like good_job.

Sidekiq Pro is great, we're paying for it! 10k a year I think.

But for people who are interested in alternatives, I'd also suggest Good Job (runs on Postgresql).

https://github.com/bensheldon/good_job

I'm the GoodJob author. Here's the class that is responsible for implementing Postgres's LISTEN/NOTIFY functionality in GoodJob:

https://github.com/bensheldon/good_job/blob/10e9d9b714a668dc...

That's heavily inspired by Rail's Action Cable (websockets) Adapter for Postgres, which is a bit simpler and easier to understand:

https://github.com/rails/rails/blob/be287ac0d5000e667510faba...

Briefly, it spins up a background thread with a dedicated database connection and doings a blocking Postgres LISTEN query returns results, and then it forwards the result to other subscribing objects.