6 ms·

Show HN: RealtimeApp – Deploy a realtime app using serverless components

98 points by ac360 8y ago

viksit 8y ago
Does this method run into the typical lambda cold start problem? If not, how does it get mitigated without say, a regular cron job polling the endpoint?
- eahefnawy 8y ago
  I believe once you're connected, your lambda will stay warm await data. But if there are no active connections, the lambda might get cold.
- ac360 8y ago
  In a websockets implementation w/ AWS Lambdas and AWS API Gateway maintaining connection state, your AWS Lambdas are invoked whenever someone 1) connects 2) disconnects 3) sends a message. This project's pattern uses a single AWS Lambda function for all of those events, for the sake of simplicity as well as performance because by receiving more events, the function is kept warmer than average. Further, when the user loads a page, if you establish the connection at that time, you warm up the function in the background by sending the connection event. Here is full Chat Application example you can deploy to test performance: https://github.com/serverless-components/RealtimeApp/tree/master/example https://github.com/serverless-components/RealtimeApp/tree/ma... When deployed to us-east-1 and using it in San Francisco, when the Chat App loads, it establishes the websockets connection immediately via React's componentWillMount(), which will warm the AWS Lambda Function. By the time I send the first chat message, the function is already warm, and it takes ~100ms on average to send and receive messages.
msoad 8y ago
Can we stop using YAML for configuration and instead use a real programming language with possibly a type interface and a compiler? So much time wasted looking up possible configurations and worse, learning that some configuration will conflict with another.
- eahefnawy 8y ago
  this could be used programmatically as well via Serverless Components. However, if your configuration is simple, that's what YAML is made for.
- ac360 8y ago
  Done! This project can be deployed with YAML or programmatically w/ Javascript. Here is an example of a full Chat Application that demonstrates how you can provision and extend this Serverless Realtime Application Component programmatically, very much like a React Component. https://github.com/serverless-components/ChatApp/blob/master/serverless.js https://github.com/serverless-components/ChatApp/blob/master...
- tashoecraft 8y ago
  I heard a good reason why we shouldn't use a programming language for configuration as it can lead to incredibly custom setups that can be crazy difficult to upgrade or for new developers to understand what's going on.
- scarface74 8y ago
  The purpose of CloudFormstion is not to tell AWS how to do something it’s to tell it the end state. How do you propose using a programming language where you can just change a resource and let the system figure out current state -> desired state and decide what needs to be created, updated, deleted, replaced? But there are CloudFormation Linters. https://marketplace.visualstudio.com/itemdetails?itemName=kddejong.vscode-cfn-lint https://marketplace.visualstudio.com/itemdetails?itemName=kd... And there is also the CF editor for Visual Studio. https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/tkv-cfn-editor.html https://docs.aws.amazon.com/toolkit-for-visual-studio/latest...
  - eahefnawy 8y ago
    Serverless Components keep track of all the resources it creates/updates and their properties locally in the .serverless directory. It also keeps it synced with the actual state of the resource on the provider (in case you've changed them in the console for example) So if you change the configuration, the component will be able to figure things out.
SwiftyBug 8y ago
This is great! Is it possible to setup only the backend and have an iOS app as the frontend?
- ac360 8y ago
  Absolutely. This project is built on Serverless Components, which are composable architectural pieces based on serverless cloud infrastructure. One of the child Components powering this project is the Socket Component, which allows anyone to provision a serverless websockets backend simply. You can use it here: https://github.com/serverless-components/Socket https://github.com/serverless-components/Socket
sarreph 8y ago
Two points on homepage design: - Why does it take ~4 seconds to load (blank) the page? Is it a PWA with no pre-loading / static initializers? - The scroll-jacking in the 1-2-3 section is broken on Safari
- superturkey650 8y ago
  Agreed on both points, it shouldn't take 4 seconds to load a landing page that's only displaying information. I'm also experiencing the same scroll-jacking problems with Chrome. Kinda disappointing because the Serverless project is very useful, and while the engineering behind the framework is great, the site has way too much going on for how simple it should be.
ac360 8y ago
Here is a real-world example built using this project. It's a full Chat Application: https://github.com/serverless-components/RealtimeApp/tree/master/example https://github.com/serverless-components/RealtimeApp/tree/ma... You can deploy this example. It contains a Create React App front-end and it uses DynamoDB on the back-end to keep track of who is connected to the Chat Application.
ramon 8y ago
what about costs? How many requests will occur in the lambda side with sockets? It's an interesting concept.
- ac360 8y ago
  Good question. As always, it depends on the use-case. But to be helpful, we've added the relevant pricing pages here: https://github.com/serverless-components/RealtimeApp/blob/master/README.md#6-pricing https://github.com/serverless-components/RealtimeApp/blob/ma...
  - ramon 8y ago
    Now I'm going crazy over the sockets after looking at the pricing!!! :)
josh_carterPDX 8y ago
Having seen a lot of these types of services there is always a question about scale. In other words, these are great for quick prototyping, but at a certain level you have to move off a service like this onto a more robust infrastructure. That being said, how hard is it to move the data off this platform and migrate it to another once you've reached scale?
- chimen 8y ago
  What exactly is the "scale" problem here?
  - josh_carterPDX 8y ago
    Since this is a general purpose platform with not much in the way of functionality. Meaning, you're not going to build the next Flappy Bird on this platform. My question is what is the ceiling? At what point do you need to move off the platform and how easy is the migration? I find people are pretty gun shy to park their data into a platform that doesn't make it easy to migrate off (Parse comes to mind).
    - ac360 8y ago
      For clarity, the platform here is Amazon Web Services. We're just providing tooling to help you build and manage serverless architectures on AWS easily.
- ac360 8y ago
  There are many case studies of AWS Lambda's scaling power and its constraints are well documented. The newcomer in the serverless architecture is AWS API Gateway Websockets, and I personally have not performed any tests using this service within a variety of use-cases at significant scale (it's still a new service). When it comes to migration, it depends on your use-case. A few suggestions which may be helpful: * Consider your data strategy (much lock-in happens at this level). Most serverless architectures leverage DynamoDB because its design pairs well with stateless compute like AWS Lambda. You can use DynamoDB within all types of architectures. * Don't use AWS API Gateway specific URLs in your application. Use custom domains. This will enable you to easily swap out your websockets endpoint. Fortunately, there is only 1 endpoint in this architecture, so there is little surface area to refactor. * Make sure you understand the cost of these serverless technologies at scale before building with them. But don't forget to factor in the reduced labor costs of using serverless technologies.
time0ut 8y ago
Amazing. I am so happy to see serverless getting more capabilities and still remaining so clean and simple. Any plans to do anything around mobile push notifications?
- ac360 8y ago
  Yes, we're looking at providing a great solution for this. In the interim, check out this Component (which is used by this project) which provides a simple webockets backend and can be used for that use-case - https://github.com/serverless-components/Socket https://github.com/serverless-components/Socket
Grollicus 8y ago
I don't see anything about deadlines here. What kind of "realtime" is this?
- jahewson 8y ago
  It's real-time web, i.e. WebSocket, not to be confused with real-time computing.
runT1ME 8y ago
Huh, interesting. Looks pretty similar to some of Fanout's stuff. https://github.com/fanout/flychat https://github.com/fanout/flychat
fabricexpert 8y ago
How can you test this or other serverless apps? Is it possible to run a local env that replicates AWS?
- Hortinstein 8y ago
  I was wondering this too a few years back when serverless started to gain traction. I remember thinking it sounded like a lot of mock infrastructure. Just did a search and found the following links interesting: https://medium.freecodecamp.org/the-best-ways-to-test-your-serverless-applications-40b88d6ee31e https://medium.freecodecamp.org/the-best-ways-to-test-your-s... https://github.com/lambci/docker-lambda https://github.com/lambci/docker-lambda It seems non-trivial to set up at this point EDIT: Still reading into it... https://serverless.com/framework/docs/providers/aws/guide/testing/ https://serverless.com/framework/docs/providers/aws/guide/te... Would love to here a best practice case study from someone who has deployed something like this
- ac360 8y ago
  We've been building serverless application dev tools for ~4 years now. In the process, we've seen incredible efforts to emulate the cloud locally. The result is usually the same: it requires tons of effort, the work is often brittle, and it still is not identical to how your app will perform in the real cloud environment (e.g. you deploy and immediately run into an API limit error). Further, the reason developers mostly want local emulation is because deploying to the cloud is simpler too darn slow. Given this experience, our hypothesis is if we can greatly increase the speed of deployment, developers will be less interested in local emulation. With Serverless Components, we're now achieving incredible results. First deployment always takes a bit longer due to initial creation of resources, some of which are global (e.g. AWS IAM), but all Serverless Components are designed to deploy as fast as possible and we're aiming for ~5s max in deployment time as our key metric. We'll go into detail later about how we've been able to optimize this.
  - vfulco2 8y ago
    I am a huge admirer as a "liberal arts grad" who grubs around technology like a blind truffle pig. Great use cases to learn from.
z3t4 8y ago
I think its brave to have real time and serverless in the same sentence when it can take minutes to "warmup"
- ac360 8y ago
  "Minutes" is a false statment for many runtimes and use-cases on AWS Lambda, including this one. I've included some performance info in a comment below.

98 points by ac360 8y ago

Does this method run into the typical lambda cold start problem? If not, how does it get mitigated without say, a regular cron job polling the endpoint?

eahefnawy 8y ago
I believe once you're connected, your lambda will stay warm await data. But if there are no active connections, the lambda might get cold.
ac360 8y ago
In a websockets implementation w/ AWS Lambdas and AWS API Gateway maintaining connection state, your AWS Lambdas are invoked whenever someone 1) connects 2) disconnects 3) sends a message. This project's pattern uses a single AWS Lambda function for all of those events, for the sake of simplicity as well as performance because by receiving more events, the function is kept warmer than average. Further, when the user loads a page, if you establish the connection at that time, you warm up the function in the background by sending the connection event. Here is full Chat Application example you can deploy to test performance: https://github.com/serverless-components/RealtimeApp/tree/master/example https://github.com/serverless-components/RealtimeApp/tree/ma... When deployed to us-east-1 and using it in San Francisco, when the Chat App loads, it establishes the websockets connection immediately via React's componentWillMount(), which will warm the AWS Lambda Function. By the time I send the first chat message, the function is already warm, and it takes ~100ms on average to send and receive messages.

msoad 8y ago

Can we stop using YAML for configuration and instead use a real programming language with possibly a type interface and a compiler? So much time wasted looking up possible configurations and worse, learning that some configuration will conflict with another.

eahefnawy 8y ago
this could be used programmatically as well via Serverless Components. However, if your configuration is simple, that's what YAML is made for.
ac360 8y ago
Done! This project can be deployed with YAML or programmatically w/ Javascript. Here is an example of a full Chat Application that demonstrates how you can provision and extend this Serverless Realtime Application Component programmatically, very much like a React Component. https://github.com/serverless-components/ChatApp/blob/master/serverless.js https://github.com/serverless-components/ChatApp/blob/master...
tashoecraft 8y ago
I heard a good reason why we shouldn't use a programming language for configuration as it can lead to incredibly custom setups that can be crazy difficult to upgrade or for new developers to understand what's going on.
scarface74 8y ago
The purpose of CloudFormstion is not to tell AWS how to do something it’s to tell it the end state. How do you propose using a programming language where you can just change a resource and let the system figure out current state -> desired state and decide what needs to be created, updated, deleted, replaced? But there are CloudFormation Linters. https://marketplace.visualstudio.com/itemdetails?itemName=kddejong.vscode-cfn-lint https://marketplace.visualstudio.com/itemdetails?itemName=kd... And there is also the CF editor for Visual Studio. https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/tkv-cfn-editor.html https://docs.aws.amazon.com/toolkit-for-visual-studio/latest...
- eahefnawy 8y ago
  Serverless Components keep track of all the resources it creates/updates and their properties locally in the .serverless directory. It also keeps it synced with the actual state of the resource on the provider (in case you've changed them in the console for example) So if you change the configuration, the component will be able to figure things out.

SwiftyBug 8y ago

This is great! Is it possible to setup only the backend and have an iOS app as the frontend?

ac360 8y ago
Absolutely. This project is built on Serverless Components, which are composable architectural pieces based on serverless cloud infrastructure. One of the child Components powering this project is the Socket Component, which allows anyone to provision a serverless websockets backend simply. You can use it here: https://github.com/serverless-components/Socket https://github.com/serverless-components/Socket

sarreph 8y ago

Two points on homepage design: - Why does it take ~4 seconds to load (blank) the page? Is it a PWA with no pre-loading / static initializers? - The scroll-jacking in the 1-2-3 section is broken on Safari

superturkey650 8y ago
Agreed on both points, it shouldn't take 4 seconds to load a landing page that's only displaying information. I'm also experiencing the same scroll-jacking problems with Chrome. Kinda disappointing because the Serverless project is very useful, and while the engineering behind the framework is great, the site has way too much going on for how simple it should be.

ac360 8y ago

Here is a real-world example built using this project. It's a full Chat Application: https://github.com/serverless-components/RealtimeApp/tree/master/example https://github.com/serverless-components/RealtimeApp/tree/ma... You can deploy this example. It contains a Create React App front-end and it uses DynamoDB on the back-end to keep track of who is connected to the Chat Application.

ramon 8y ago

what about costs? How many requests will occur in the lambda side with sockets? It's an interesting concept.

ac360 8y ago
Good question. As always, it depends on the use-case. But to be helpful, we've added the relevant pricing pages here: https://github.com/serverless-components/RealtimeApp/blob/master/README.md#6-pricing https://github.com/serverless-components/RealtimeApp/blob/ma...
- ramon 8y ago
  Now I'm going crazy over the sockets after looking at the pricing!!! :)

josh_carterPDX 8y ago

Having seen a lot of these types of services there is always a question about scale. In other words, these are great for quick prototyping, but at a certain level you have to move off a service like this onto a more robust infrastructure. That being said, how hard is it to move the data off this platform and migrate it to another once you've reached scale?

chimen 8y ago
What exactly is the "scale" problem here?
- josh_carterPDX 8y ago
  Since this is a general purpose platform with not much in the way of functionality. Meaning, you're not going to build the next Flappy Bird on this platform. My question is what is the ceiling? At what point do you need to move off the platform and how easy is the migration? I find people are pretty gun shy to park their data into a platform that doesn't make it easy to migrate off (Parse comes to mind).
  - ac360 8y ago
    For clarity, the platform here is Amazon Web Services. We're just providing tooling to help you build and manage serverless architectures on AWS easily.
ac360 8y ago
There are many case studies of AWS Lambda's scaling power and its constraints are well documented. The newcomer in the serverless architecture is AWS API Gateway Websockets, and I personally have not performed any tests using this service within a variety of use-cases at significant scale (it's still a new service). When it comes to migration, it depends on your use-case. A few suggestions which may be helpful: * Consider your data strategy (much lock-in happens at this level). Most serverless architectures leverage DynamoDB because its design pairs well with stateless compute like AWS Lambda. You can use DynamoDB within all types of architectures. * Don't use AWS API Gateway specific URLs in your application. Use custom domains. This will enable you to easily swap out your websockets endpoint. Fortunately, there is only 1 endpoint in this architecture, so there is little surface area to refactor. * Make sure you understand the cost of these serverless technologies at scale before building with them. But don't forget to factor in the reduced labor costs of using serverless technologies.

time0ut 8y ago

Amazing. I am so happy to see serverless getting more capabilities and still remaining so clean and simple. Any plans to do anything around mobile push notifications?

ac360 8y ago
Yes, we're looking at providing a great solution for this. In the interim, check out this Component (which is used by this project) which provides a simple webockets backend and can be used for that use-case - https://github.com/serverless-components/Socket https://github.com/serverless-components/Socket

Grollicus 8y ago

I don't see anything about deadlines here. What kind of "realtime" is this?

jahewson 8y ago
It's real-time web, i.e. WebSocket, not to be confused with real-time computing.

runT1ME 8y ago

Huh, interesting. Looks pretty similar to some of Fanout's stuff. https://github.com/fanout/flychat https://github.com/fanout/flychat

fabricexpert 8y ago

How can you test this or other serverless apps? Is it possible to run a local env that replicates AWS?

Hortinstein 8y ago
I was wondering this too a few years back when serverless started to gain traction. I remember thinking it sounded like a lot of mock infrastructure. Just did a search and found the following links interesting: https://medium.freecodecamp.org/the-best-ways-to-test-your-serverless-applications-40b88d6ee31e https://medium.freecodecamp.org/the-best-ways-to-test-your-s... https://github.com/lambci/docker-lambda https://github.com/lambci/docker-lambda It seems non-trivial to set up at this point EDIT: Still reading into it... https://serverless.com/framework/docs/providers/aws/guide/testing/ https://serverless.com/framework/docs/providers/aws/guide/te... Would love to here a best practice case study from someone who has deployed something like this
ac360 8y ago
We've been building serverless application dev tools for ~4 years now. In the process, we've seen incredible efforts to emulate the cloud locally. The result is usually the same: it requires tons of effort, the work is often brittle, and it still is not identical to how your app will perform in the real cloud environment (e.g. you deploy and immediately run into an API limit error). Further, the reason developers mostly want local emulation is because deploying to the cloud is simpler too darn slow. Given this experience, our hypothesis is if we can greatly increase the speed of deployment, developers will be less interested in local emulation. With Serverless Components, we're now achieving incredible results. First deployment always takes a bit longer due to initial creation of resources, some of which are global (e.g. AWS IAM), but all Serverless Components are designed to deploy as fast as possible and we're aiming for ~5s max in deployment time as our key metric. We'll go into detail later about how we've been able to optimize this.
- vfulco2 8y ago
  I am a huge admirer as a "liberal arts grad" who grubs around technology like a blind truffle pig. Great use cases to learn from.

z3t4 8y ago

I think its brave to have real time and serverless in the same sentence when it can take minutes to "warmup"

ac360 8y ago
"Minutes" is a false statment for many runtimes and use-cases on AWS Lambda, including this one. I've included some performance info in a comment below.