7 ms·

I don’t mean to discount the work done here, but why would a dev team build this themselves these days? There are many practically infinitely scalable services

• thewarrior 7y ago
  Pretty soon your app is just a bunch of proprietary cloud provider products glued together and now there’s vendor lock-in and much less flexibility. You might want to throttle messages based on user settings or say ML models to avoid too many annoying messages. For critical stuff you might want to switch over to email or SMS. These are startups that have the funding to do this kind of thing. This is a core part of the stack for any such company.
  • kondro 7y ago
    If that's your concern, lean on Firebase. You have to use Firebase to deliver messages to Android anyway, having it deliver to APNS as well you get for free with that implementation. Maybe you do want to do those things, but this implementation doesn't, nor do they mention the intention to do that. But if you did, SNS also provides implementations for delivering SMS and Email (preferably through SES). Startups shouldn't waste their money on this type of thing, especially if you consider most startups will fail. Vendor lock-in is a pretty stupid thing to worry about for an early-stage start-up (and I argue it's stupid to worry about long-term too if that vendor is AWS, Google or Azure who are all very competitive with each other).
    • thewarrior 7y ago
      I’m not disagreeing just want to point out that this company has raised 3 billion dollars in total. So imo it’s worth it for them they have the money. I wouldn’t do all of this starting out.
    • TheCycoONE 7y ago
      Having a middleware to abstract firebases API from the services makes sense if just to minimize the disruption the next time Google changes it. I've always left tokens up to the callers to sort out before calling the notification service, but I see the appeal of centralizing it if you have a lot of small products. I agree there is no longer any good reason to directly target APNS. Nothing in the article really said how they got to millions an hour. In my experience the notifications are cheap enough to send that that figure is easy to obtain without any special effort on the push side. It's also embarrassingly parallel/easy to scale. How everything else scales around that (recipient filtering, reporting) is the interesting part.
    • ummonk 7y ago
      Gojek is way past the “most startups will fail” stage though.
  • tanilama 7y ago
    I don't think vendor lock-in is what small startup should worry about.
    • abdulmuhaimin 7y ago
      They are not small though. Gojek is big in Indonesia specifically
  • discordance 7y ago
    Efficiently handling million of events per second (not per hour) using whatever cloud PaaS is a no brainer these days. The lock-in is worth it when you can reliably move that fast. If you're really worried about lock-in, most event based PaaS support running containers. Moving between clouds would then just be the glue-work around your containers.
  • SkyPuncher 7y ago
    Honestly, how many companies DON'T rely on some proprietary cloud provider at some point? * SMS - You can't just interface directly with some cell company (which is proprietary anyways). * EMAIL - Have you tried to send your own emails in the past decade? Just use a provider. * Push Notifications - Have to use Firebase for Android anyways. ---- Your core stuff should limit proprietary stuff. Edges are going to change over time no matter what, might as well use stuff that makes you faster now.
    • zAy0LfpBZLC8mAC 7y ago
      > * SMS - You can't just interface directly with some cell company (which is proprietary anyways). Wut? People don't even know anymore that you can use cellphones to send SMS?! (And no, that's not the only option, SS7 works just fine as well.) > * EMAIL - Have you tried to send your own emails in the past decade? Just use a provider. Have you? Talking nonsense does not make expertise ...
      • SkyPuncher 7y ago
        Email in particular. Sending your own isn't the problem. Managing your reputation, deliverability, etc just isn't fun to deal with.
• 9nGQluzmnq3M 7y ago
  Did you read the post? They're using Firebase messaging, but that only covers a part of their workflow.
  • kondro 7y ago
    They’re only using Firebase for Android delivery (which is mandatory anyway). But it is just as happy to deliver to APNS at $0 as well with near infinite scalability. The actual delivery component of their messaging system is unnecessary.
• basilgohar 7y ago
  One big factor is being free from bundling proprietary, vendor-specific libraries that may also leak user's information or otherwise increase the security risk footprint of your app. Having control over the services that make up the core of your business, as opposed to outsourcing and relying on 3rd-parties, can be very freeing and also cost effective in the long run.
  • harryh 7y ago
    Once you're hosting on AWS you've pretty much already crossed that particular bridge.
• gdeglin 7y ago
  I cofounded OneSignal for this reason. We were previously a game studio that built an in-house solution. It was a huge maintenance headache and a distraction. Eventually, we realized that so many companies were one-off push implementations and decided to focus our efforts on building a really great third-party solution. Firebase and SNS have since entered this market as well. I'm obviously biased, but I honestly can't recommend them. They work for some of the basics, but there's been very little innovation in either product and occasional service issues that go unsolved for a long time. They also don't make any money from them, which should be a concern for anyone that plans to use these services for such a core part of their business.
• hw 7y ago
  It's not hard to do what they did, so I'm not surprised they did it themselves. It's just simple async queue processing, and doesn't really need a lot of sophistication, especially at just 1M notifications per hour. Now if they need to process a few orders of magnitude more, then AWS SNS would probably be a good next step.
• dragonsh 7y ago
  Gojek is a super app in Indonesia serving a population of 264 million. They can afford this level of engineering and are required to do it, to stay competitive. They have millions of motorcycle driver (called gojeks) for whom they are trying to find jobs while idling waiting for passengers to transport. If uber built these no one will question them why don't they use some off the shelf solution. Gojek is a google cloud customer and under their startup program - surge. So I am sure they are aware of the solution proposed. They don't call themselves technology company but company which helps gojek drivers to find jobs and earn extra. In the process they became a food delivery, transportation, payments, courier company. In spite of this they still focus on their primary objective to find jobs for gojek and let them earn extra for better living. Before Gojek app most of the drivers were just idling waiting for passengers, now with a $25 Kai OS feature phone [1], they can just receive a message and earn instead of just idling, they don't have to use iPhone or Android or some heavy OS. Indeed based on social survey some of the drivers could increase there earning 3-4 times based on how willing are they to take up additional jobs. I believe the beauty of Gojek lies in its model to focus on finding jobs and developing solution to help those motorcycle drivers using technology. Although they extended it to cars. I am intrigued by their idea since its not a copy of Uber, but a solution to a problem local to Indonesia, which can extend to any country in the world finding jobs to do while idling and earn more. [1] https://en.wikipedia.org/wiki/KaiOS https://en.wikipedia.org/wiki/KaiOS
  • hello_moto 7y ago
    > They can afford this level of engineering and are required to do it, to stay competitive > If uber built these no one will question them why don't they use some off the shelf solution Uber and Gojek don't have the same talent pool so we can't compare them as Apple-to-Apple. It is a risky move for Gojek and not for Uber because of the talent pool in their respective area.
    • dragonsh 7y ago
      Why would you think Gojek will not have a talent and cannot manage engineering? If you have used their app and done a review of their platform comparing it with Uber, can you please share. Indeed Uber did try to enter Indonesia they failed, they were out of most of South East and East Asia, because they don't have enough engineering talent to build a system for those specific countries, local companies like Grab in Singapore, Gojek in Indonesia, Didi in China beat them. So why would you think those companies do not have a talent to build systems better suited to their own environment than Uber.
• hello_moto 7y ago
  Engineering Pride (and exercise for future employment). While this might sound condescending but hear me out: - if you keep doing the same thing like everybody else out there, gluing APIs from cloud-vendor, you won't stand out. - if you're a company of _that_ size (Uber, Gojek), you gotta do something big because the name/brand is associated with "Engineering" excellence - if you're a leader (or in management), would you tell your employee to "suck it up" and do the boring stuff like everybody else? or would you empower them to do more? hype them up? this is a strategy for keeping them happy too. I don't begrudge that. That's how companies evolve: they start small and scrappy, they grow very fast, and they're at the level where "doing simple stuff" won't get you promotion or you won't have something cool to show during the interview for your next job. It's work dynamic.
  • deleted 7y ago
    [deleted]
• shanipribadi 7y ago
  ``` Surely there are other more important features delivery business value to be done rather than re-inventing (and then scaling and supporting) the delivery of mobile notifications. ``` the business value the service provided is that this allow the engineering organization to scale. Gojek has couple hundred engineers, split across multiple teams, where each teams own multiple services/products/applications, each with their own development cycle. Having a single abstraction provided as a service helps to mitigate the risks involved in changes to implementation details and external dependencies (e.g. GCM deprecation) since it abstracts it away completely.