Live data from Hacker News

McDonalds Event Driven Architecture

medium.com

131–134 of 134 posts

Re: McDonalds Event Driven Architecture

#131
post #112
post #60

I am, for better or worse, a "heavy user" of the McDonald's app. And unfortunately, all this architecture somehow still misses so many usability issues. The most annoying one, is that the app always defaults to the closest location "as the bird flies." Despite the fact that I have "favorited" a different store, and also my last 5 or 10 orders were placed at this favorite store, the app ALWAYS defaults to the first st…

No concerns about privacy issues? The Canadian iOS version of the app insists on running in background and complains of you disable precise location. This is slimy.

You give up location data in exchange for discounts, that’s the bargain you agree to by using the app, whether you realize it or not.

I refuse to play this game. When I go to McDonalds I pay in cash and don’t use the app, it’s insulting to be offered 20% off to allow McDonalds to track my precise location, no thanks.

Re: McDonalds Event Driven Architecture

#132

Both my partner and I always have trouble with the McDonald's app (for ordering). I use Android, she uses iOS. As a developer, I've said to myself "This feels like a React Native app that's calling into a mess of microservices" (having worked on that type of project more than once myself). Anyway, I only skimmed the article, but I had a chuckle seeing the title of this article pop up on HN at all.

I wished more people used a regular website for these kinds of applications. It's a form. What's the problem?

A web form cannot track your precise location 24 hours a day, but an app can.

Re: McDonalds Event Driven Architecture

#134
post #125
post #36

Earlier quoted context omitted.

>with globally distributed teams of developers with diverse skill levels The last place I worked with a monolith (~100 developers) put quite a bit of work into making sure everyone didn't step on everyone else's toes. This mostly propagated as optimizing CI and improving test quality (since a single flakey test could derail everyone's build) As to why "microservices" versus a few "normal" sized services I'm not sure…

At my previous job we used "microservices" for lack of a better term, but really they were "business services". We tried calling them "business services", "macroservices" or just "services", but it was confusing so in the end we just stuck with "microservices".

I think we (as an industry) are basically just revisiting SOA https://en.m.wikipedia.org/wiki/Service-oriented_architectur... (but maybe with a little less Java this time)
Post reply on HN