c89X's comments

this is an immensely reassuring, and at the same time motivating comment

I think the point of the article is not whether the tracking apps are relevant - or damaging to privacy, which they very well may be. The point is that these decisions should be made by European governments, nót (American) corporations.

eh, a vaccine becoming available in the next year or two?

Thanks, really appreciate the pros and cons here. To be clear, and I understand the confusion: I'm actually building more or less a monolith with a RDBMS to encapsulate most of the business logic of my problem domain.

However, for various parts of my application that seem high-complexity, high-impact and non-competetive edge (such as authentication and credit card handling) I want to outsource to external services (Auth0 and Stripe). This brings with it the challenge of managing state, and consistency across various external services (on top of the state I manage internally).

The reason microservices is mentioned in the question, is because I believe these problems generalise from my specific case, to microservices.

I like this approach: it closely matches my initial instincts of having a 'transaction' table for each type of event, with columns for each of the steps. The reason I'm weary of this approach, is because I have done an implementation of this in the past but it turned out to become a nightmare - this is most likely due to a combination of the complexity of that particular domain, my inexperience with this type of problem and external pressures.

I did find some pretty good resources on Sagas - do you have any thought on comparing Sagas pro/cons vis-a-vis this approach?

So you would recommend implementing authentication and handling credit cards from scratch? The reason I'm going with this approach is because although I do use a monolith and a single (hosted) DB for my business logic my understanding was that implementing high-impact, high-complexity (non competitive advantage) systems like authentication and credit card handling are best 'outsourced'.

This outsourcing of high-impact, high-complexity does come with the disadvantage of now having to deal with external services. As far as I can tell, the atomicity/transactional problem with these external services generalises to microservices - hence the microservices tag.

thanks, useful resource!

Thanks. From my (limited) understanding this sounds a lot like the Sagas that have been suggested by others - does that match your intention?

This approach makes a lot of sense. I was unaware of the concept of idempotency keys (nor did I know Stripe supported them). I'm actually trying to avoid complexity, which is why I turned to Auth0, Stripe (i.e. external services) to handle most of the logic for me - I'm sure I just need to figure out how to correctly apply those! Thanks for your input!

The way I have tried to implement (very likely, shoddily) idempotency is to have each mutation on an external service (say creating a customer in Stripe, corresponding to an account already administered in my database) first check if a customer with that ID already exists, and if not to create it - otherwise use the existing object (Stripe customer in this example).

``` user = Database.get_user(my_user_id)

if (Stripe.customer_exists(user.id) { return Stripe.get customer(user.id) } else { stripe_customer = Stripe.create_customer(user.id, user.email) Database.set_user_property("stripe_customer_id", stripe_customer.id) return customer } ```

The problems here are multiple, but at the very least I see the possibility of very nasty bugs if somehow the `customer_exists` call returns a false negative - this will cause the same customer to be created in Stripe twice (and thus potentially be charged twice). Another, more likely, issue is that between the `Stripe.create_customer` call and the `set_user_property` there may be an unexpected event (service/network goes down, whatever) failing to store the property - leading to a duplicate Stripe customer the next time the above code is executed. On top of that, I find it pretty difficult to reason about a code base chock full of this type of logic (perhaps that is just my personal limitation though!).

That's it! Not sure how I never stumbled upon this. Thanks!

My understanding was that Redux had become largely redundant now that React Hooks have been released. I have only entered the React domain recently, so maybe someone can shed some light on when to use Redux vs. React Hooks?

Actually I didn't know about rsnapshot. Thanks, I'll give that a try.

I use https://borgbackup.readthedocs.io/en/stable/ and a local (on-site) NAS. I have yet to find a good solution for off-site backups, privacy concerns prevent me from using the usual (commercial) options.

thanks!

I’m missing the “Disconnect” action for Wifi and Bluetooth. I’d like to be able to increase text size automatically when getting in the car (based on bluetooth connecting to the car) for improved visibility, but to undo it when I exit the car. Unfortunately that doesn’t seem to be possible (yet).

In my opinion, retaining equity, this early in the process, does seem unfair. By far most of the value of the company is yet to be created and if you choose to not be a part of that, it's hard to see why you would have a stake in it at all.

Leaving you 'empty handed', or only paying you the share of the incorporation fee also sounds unreasonable - you did invest time and effort and that largely remains unvalued in that case.

In the past I have dealt with similar situations by agreeing on the amount of hours and effort spend, and attach a market value to that. The leaving party then is paid that amount (either in whole, or stretched out over a period) and no equity is retained.