React/Relay front end. Postgraphile/Fastify backend. Postgres database. Typescript. The most OP type safe stack. One change in your database propagates throughout your stack.
Awesome writeup! Just had a couple comments/questions.
> Not adopting an identity platform early on
The reason for not adopting an IDP early is because almost every vendor price gouges for SAML SSO integration. Would you say it's worth the cost even when you're a 3-5 person startup?
> Datadog
What would you recommend as an alternative? Cloudwatch? I love everything about Datadog, except for their pricing....
> Nginx load balancer for EKS ingress
Any reason for doing this instead of an Application Load Balancer? Or even HA Proxy?
For datadog, unfortunately there's no obvious altnernative despite many companies trying to take marketshare. This is to say, datadog both has second to none DX and a wide breadth of services.
Grafana Labs comes closest in terms of breadth but their DX is abysmal (I say this as a heavy grafana/prometheus user)
Same comments about new relic though they have better dx than grafana.
Chronosphere has some nice DX around prometheus based metrics but lack the full product suite.
I could go on but essentially, all vendors either lack breadth, DX, or both.
+1 graphile worker. we use it to coordinate all of our background tasks and events (use slayQ https://slayq-docs.vercel.app which is kind of a wrapper around it)
I have a Twilio number that forwards to my real number, and the Twilio number is a contact in my address book. So anyone who gets the special Twilio number (eg, contractors, preschool, etc) can call from whatever number and never be blocked.
This only works if Twilio successfully blocks the spam calls before they are forwarded. I guess I’m not surprised that Twilio does a much better job of it than any of the dinosaur carriers.
Sure, but so far so good. The only "spam" call I get is people trying to get ahold of the previous owner of the phone number, but I find that far less annoying than marketing robo calls.
In some countries yes. In the UK if you want to make 20 or more roles "redundant", you have to group employees by reasonable groups, rank them by reasonable measures, and then let go those at the bottom. You also have to consult with employee representatives at each stage. Then, employees are entitled to minimum compensation amounts and that isn't taxed in the normal way. Much of Europe has similar or stronger processes.
I think another key aspect of "redundancy" in the UK is that it is a claim that the person's role is no longer needed, and hiring someone else for that role soon afterwards can be seen as invalidating that claim and thus invalidating the dismissal.
Which is why new roles are (or should be) advertised as slightly different - for legal protection against former employees taking you to court for fake redundancies.
Legally, they are supposed to treat mass firings differently than just individual firings. WARN act would require advanced notice for firing of 50 or more persons from a location. The location of travel/remote employees would be their nearest office.
Wrong. The WARN act does not differentiate between mass firings and mass layoffs of full-time workers. Requirements change once certain firing thresholds are crossed. Firing enough people to cross those thresholds, telling them individually that they are being fired for performance reasons, and not giving advanced notice would be a clear violation. https://www.dol.gov/sites/dolgov/files/ETA/Layoff/pdfs/Worke...
Thanks, I see it now. The document you linked describes three applicable situations for layoffs, but then goes back and says those situations also apply for a bunch of things which are not layoffs.
You do unless you did something illegal or ethically wrong. Not meeting some company goal or expectation isn't enough. Killing a system with a rookie command isn't enough. Being an asshole isn't enough.
In some circumstances there absolutely is a difference in the amount of money you will be entitled to in the case of being fired vs. being made redundant. It can be on the order of several months of pay. You will also see employers simply make the working conditions incredibly miserable for their employees on the hope that they'll quit instead of the business needing to make them redundant.
It’s harder to successfully sue for wrongful termination if they were laid off as one of many. Perhaps deceptively firing under the guise of layoffs opens the door to greater scrutiny.
You won't be getting unemployment benefits if you are fired. Also professional reputation, negotiation of severance terms, getting a positive reference, rehireability.
No, you don't. Oregon Unemployment, Claimant Handbook, Section 6. Source: I helped a friend through unemployment. He was fired from work, and his employer provided a false reason for the firing, triggering denial of benefits. We looked at his options, and it would've been cost-prohibitive to retain a lawyer to fight it, which would've been required.
Have you gone through this process? You do not just get your benefits. You might need a hearing, a letter, a lawyer. Being fired is handled very differently with regards to unemployment than laid-off. Are you claiming otherwise.
Always. And sometimes they are a big customer who screwed up something big and if you can not restore it easily, you have to go find a DB backup and write some scripts to bring it back anyhow.
Soft delete is a necessity in SaaS. And then combine it with hard delete either triggered manually (empty recycle bin) or time based (after a month, etc.)
The way I like to solve this is using database snapshots. Just make sure you have an incremental snapshot setup for:
- Last round hour
- Last round day
- Last round week
These periods can be adjusted to your/client needs. If you need something that was deleted, you restore the snapshot into a new live db and copy whatever you need. You could charge for solving "I just shot myself in the foot" support requests based on the cost of restoring those snapshots.
From my experience, this is much cleaner than having a spread of soft delete columns all over the codebase.
I mean, if you have a functional fast acting organization, maybe.
It seems in the vast majority of organizations I talk to, this is not how things work at all. To get a db restore on a different box you have to have at least 2 different teams involved. One to provide a machine/vm/aws instance to restore to, and another to provide the snapshot/backup.
With a soft delete all you need is the application administrator that has SQL access, which is typically far closer to the person that needs the data restored than the operations team is, hence it gets 'fixed' in a more timely fashion.
That's unfair. For the snapshot scenario, you described the bureaucratic sad path for doing it. For the soft delete, you used a happy path.
Let's compare both in either best-scenario or worst-scenario:
Snapshots on good team with no bureaucracy: Everything is automated. Even retrieval is automated via individual, commited, retrieval commands. Setup is done once and requires little maintenance, retrievals can be reused if fallen in same category (restore account, restore conversation, etc).
Snapshots on shitty team with lots of bureaucracy: Everything is manual, AWS-panel operated and only a few people have access, you have to escalate to initiate the proccess.
Soft deletes on good team with no bureaucracy: Everyones respect the soft deletion, no one queries it or do funny stuff unless for recovery purposes. The soft delete related columns, structures and tools are standardized.
Soft deletes on shitty team with lots of bureaucracy: There might be multiple, competing standards for soft delete column naming and structure. Other teams ignore the soft delete and query hidden data either knowingly (tricky hacks) or unknowingly (data team unaware of soft delete model), you can't do shit about it. When it breaks your soft deleted data, you're the one who has to fix it.
If we put external stuff in the mix (teams, people, org structures) we can spin it the way we want, but that doesn't reveal much information about the technical issue itself (having some kind of reasonable data recovery).
Pre-COVID19 pandemic, when the plans to develop and open part of the Westside Pavillion as a Google office was shared with employees, many of the engineers based out of the Los Angeles (Venice) office declared their preference to quit and find another job elsewhere. This was because Google was planning to close the crowded Venice Office (Binoculars Building) and reassign those employees to the new Westside Pavillion office.
Many Googlers live on the LA Westside (Santa Monica, Venice, West LA, Culver City, Playa Vista), often close enough to bike to work.
Or as the other poster said, the South Bay Beach Cities. However the beach cities are almost 1hr driving to/from the Venice Office. It's often more than 1hr to/from the beach cities to the Westside Pavillion.
