
Show HN: RealtimeApp – Deploy a realtime app using serverless components - ac360
https://github.com/serverless-components/RealtimeApp
======
msoad
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.

~~~
scarface74
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=kd...](https://marketplace.visualstudio.com/itemdetails?itemName=kddejong.vscode-
cfn-lint)

And there is also the CF editor for Visual Studio.

[https://docs.aws.amazon.com/toolkit-for-visual-
studio/latest...](https://docs.aws.amazon.com/toolkit-for-visual-
studio/latest/user-guide/tkv-cfn-editor.html)

~~~
FakeComments
CloudFormation YAML being terrible is well known, to the point that AWS did
precisely what that person suggested.

[https://github.com/awslabs/aws-cdk](https://github.com/awslabs/aws-cdk)

They are in the process of releasing a kit to define your infrastructure
programmatically, and let them deal with the mess of CloudFormation as a
compiled IR they send to their backend when you deploy.

~~~
scarface74
That’s not what CDK does:

You’re still defining your resources declaratively - just with type checking -
at least if you’re using a statically typed language. If not, you’re still
just getting runtime errors when you run your program. It might catch some
things before you run your template - but so will a linter.

Neither will catch issues like using a subnet that doesn’t exist or using an
AMI that doesn’t exist.

~~~
FakeComments
> Neither will catch issues like using a subnet that doesn’t exist [...]

The CDK does: you’re either explicitly bypassing the safety checks, are
explicitly importing a value (which necessarily is validated at runtime), or
have to provide a subnet definition to instantiate the relevant object.

You then use these programming language constructs to implement higher level
ideas like applications, fully in a programming language.

------
ac360
Here is a real-world example built using this project. It's a full Chat
Application:

[https://github.com/serverless-
components/RealtimeApp/tree/ma...](https://github.com/serverless-
components/RealtimeApp/tree/master/example)

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.

------
time0ut
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
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)

------
sarreph
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
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.

------
josh_carterPDX
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
What exactly is the "scale" problem here?

~~~
josh_carterPDX
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
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.

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

~~~
ac360
"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.

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

~~~
ac360
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)

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

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

------
runT1ME
Huh, interesting. Looks pretty similar to some of Fanout's stuff.
[https://github.com/fanout/flychat](https://github.com/fanout/flychat)

------
viksit
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?

~~~
ac360
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/ma...](https://github.com/serverless-
components/RealtimeApp/tree/master/example)

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.

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

~~~
ac360
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/ma...](https://github.com/serverless-
components/RealtimeApp/blob/master/README.md#6-pricing)

~~~
ramon
Now I'm going crazy over the sockets after looking at the pricing!!! :)

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

~~~
ac360
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
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.

~~~
ac360
Backgrounds don't matter. Software development should be accessible to
everyone. Serverless tech will greatly help enable this.

