lvice
> Looking at the documentation directly, what they advise you to do is kind of the worst idea they could come up with: https://stripe.com/docs/webhooks/signatures – you need custom logic[2] to verify that their MAC ("signature" they call it incorrectly) is valid and you need to configure a different secret for each of your endpoints
It certainly help that I use their official SDK, but it's one line of code to add the signature validation. Also, I'm not sure why you would want to create a lot of endpoints to listen to these webhook. I simply have one, and the Stripe SDK helps me in determine the event type, its deserialization, etc.
> Payment process information is such a vital business concern that "let's try to call them and if that fails... well we tried" is broken on principal alone
That's not how it works. The webhooks keep retrying with exponential backoff until they succeed. You can also manually retrigger them for individual events.
> The obvious approach is to have an event list which you as customer long-poll or just poll every few seconds if your framework doesn't support async well
Nothing is preventing you to do that. In fact, in my codebase I do polling to the Stripe API as a fallback to check if payment is successful in case there are issues with webhooks. But it's nice to have the webhook telling you immediately if a payment fails/succeed, in order to give feedback to the user fast about the status of his payment (and not wait the next long polling iteration)
Not everything on Stripe is perfect, but I do find it really pleasant to work with in general
- Trouble sleeping
- Not being able to enjoy my holiday / weekend due to the thought of having to go back to work with an increased backlog
- Enhanced imposter syndrome
- Work productivity drop
- Complete lack of purpose in the daily work
All of the above built up very slowly and I didn't realize until things got overwhelming. The good news for me was that all of the above disappeared almost instantly when I switched jobs.
Using the Actor Model provided by Akka and an event sourced architecture does not fit very well with the request-response model of HTTP. Commands are usually issued in a fire-and-forget pattern, with resulting events being pushed to the client in a completely asynchronous way.
By using websockets via SignalR, we can better accomodate this pattern on the client code as well. On top of being a better fit with our backend architecture, it also provides some benefits in the frontend such as:
- Limited availability items disappear as soon as they actually are not available anymore, without the client having to refresh
- We can integrate more easily with payment gateways where payment confirmation usually arrives via a server side webhook. We can then easily push the "payment succeeeded" event to the client as soon as we receive it, without polling.
- Even the backoffice benefits from real-time, as all backoffice users are guaranteed that when they look up a customer/orders/products, they are looking at the most up-to-date information, even if somebody else edits the same record at the same time, or the record is updated by external APIs/scheduled job.
- We can provide easily real-time dashboboards that are listening to the feed of events being persisted
- Persistent connections make horizontal scaling more difficult
- Web Application Firewall don't usually support payload scanning for threats over websocket messages (eg. Cloudflare)
- If you need to integrate with third parties, you may end up needing a standard REST API anyway, since it's a lot less common to integrate via websockets (especially server-side). You then end up with two APIs. Also, websockets have less standard tooling for automatic documentation purposes such as Swagger/OpenAPI
- It's harder to load test the system, difficult to estimate the breaking point of the infrastructure via websockets
- HTTP Status Codes provide a standard error mechanism to HTTP server calls, while with websockets it's entirely up to you (which can be a good and bad thing)
- You need to manage explicitly situations where the connection drops and what to do when it recovers, as you may have lost some data in the meantime
- You give up a lot of standard mature tooling for caching and rate limiting
Weirdly, it only happens to the desktop site, if I access it via mobile I get mostly normal suggestions.
Well, not sure if that's fair. Until you accept at least the "strictly necessary" cookies, it makes sense that you get prompted the consent at every visit, since no cookies are saved.
This being said, I've been burned already several times by the complexity and its raw power. The codebase tends to become verbose and difficult to navigate (everything being an ActorRef). Debugging is difficult and coding is challenging for junior engineers, as you said. I found it very unforgiving to mistakes, and it's easy to shoot yourself in the foot if you use the abstractions without knowing very well what's going on under the hood. Edge cases can be very tricky to manage.
I'm still very conflicted about it. One one side the services powered by Akka are quite stable and performant, but I'm not sure the complexity justifies the means.
When I found out the company was founded in Italy (my home country) I was very pleasantly surprised, as tech companies with such well designed products are very rare over here. Building a friction-less editor for engaging, reliable email layouts is a complicated engineering problem, and what your team built is absolutely outstanding.
Good job, really :) the company success is fully deserved.
While I played, I came to similar conclusions to the article. Building factories in this game is very very similar conceptually to building software. I ran into exactly the same problems that I ran while I build software like:
- If I don't plan ahead enough the scope and layout of the factory, I end up with a spaghetti mess that is very difficult to rectify (technical debt)
- If I plan too much ahead, I overwhelm myself without even starting. The amount over-engineering and over-preparation becomes counterproductive and demoralizing.
- Starting new factories is fun. Maintaining and extending a factory that is starting to show serious design issues is a chore. I always tend to want to scrap the factory and start fresh.
- While designing a factory, modularization is key. You can go with a "monolithic" factory where you provide all possible materials as input, and try to build everything as output. It is very efficient transportation wise, and can centralize all management, but it can and it will become an unmaintainable mess. You can also design factories as "microservices", where each factory is a very compact, clean and scoped. It will only produce nails, or rubber, or copper wire. When you need to increase production of that item, you just duplicate the module (horizontal scaling). It seems fantastic at first, but the issue is now transportation. Dozens of micro-factories have to communicate with themselves to combine and produce more complicated items. The physical distance makes planning transportation a logistic and construction nightmare. So you have to find the right compromise between monolithic and micro-services.
I think I agree with the article that you can extract a lot of information about how good a person can be at software development by the way he plays Factorio/Satisfactory. Not so practical though :)
Due to extremely skewed media coverage of the recent events, it may also be almost justifiable as a general reaction of population. If people are told that a vaccine has a rare but lethal side effect, and they are not in at-risk category, and there are two other vaccines that seem safer, it is almost reasonable to wait the other one. The main issue has been communication by media which made the investigation into side-effect seem much more severe than what it really was, undermining people trust in AZ. I think newspapers made an horrible job at it.
I would definitely still get the AZ vaccine, but I kind of understand where people are coming from, given the message given by media and their number-illiteracy that does not allow them to understand probability and the scale of numbers.
Living in Italy, sometimes it's hard to see why the country is still in the top 10 economies in the world, due to the fact we lack mega-corps and global consumer brands (luxury aside). The truth is that Italy is all-in on small businesses, with thousands on niches companies that fill a very specific spot in the world supply chain. I really hope that this model proves to be sustainable and we can find a path to growth again at some point.
A relationship between a supervisor and his direct reports, both in academia and industry, is impacted by the power that the supervisor can exert. The relationship between a supervisor and his PhD students is not the same as a manager and his direct reports in industry because:
- The students are invested and committed into their PhDs for several years. It is much harder to change path or mentor compared to just change jobs. The energy and resources that the student needs to invest to apply a change are significantly higher, often involving moving to a different city.
- The reward of a job is, for the most part, the monthly paycheck. A PhD is a long-term investment that must be completed in order to have value. An employee that quits a job after one year is not an issue, and it is considered "experience", but quitting a PhD half way through can be perceived as a failure.
- Professors in academia have almost unlimited decision power in how they manage their budget and their reports. It can almost feels like an absolute monarchy.
- This may be anecdotal, but I feel like the role of professor in academia can attract people with larger egos and smaller empathy, especially in scientific subjects.
All of these points, combined with a bad supervisor, are fantastic fuel for anxiety and unhappiness. There is no worse thing that, after so much work, feeling that you have no control over your situation and you have no margin to improve it, without significant additional sacrifices.
- Canvas apps: worth it only for very simple applications that interact with another MS datastore (Sharepoint, CDS/Dataverse) and services. If you mostly need to interact with custom APIs, a simple custom webapp is probably a safer choice.
- Power Automate: stick to very simple flows, take advantage of the connectors but avoid at all cost complex business logic within the flow itself
- Model-driven apps: more interesting in my opinion. They effectively are mini-instances of Dynamics CRM, and you get A LOT of functionality out of the box. You can't tune the UI much, but you get the benefit to build an "interactive database" very quickly, with support for RBAC system, OData REST APIs, Views, Workflows, C# plugins, dashboards. If you need an internal application, used only by a few people (licensing), where you need an interactive data-store without complex requirements on business logic and custom UIs, then I think Model-driven apps can be terribly effective. Now, if only the licensing wasn't so damn complicated...