Good evening to everybody also from my side and welcome to this little session to see how locize leverages serverless. I am pleased that so many are interested in this first meet-up about serverless topics.
My name is Adriano… I maintain and contribute some open source projects… And together with Jan (sitting exactly here) I’ve created locize.
locize is a localization as a service solution. Localization means making a product suitable to use in a particular country or region. => So the translation and translation management process. This starts immediately after or even in parallel with the internationalization process…
How many developers are here this evening? Who knows what internationalization means? Internationalization is the process that triggers you i.e. to: ensure data space so that messages can be translated into languages that require more characters support international character sets instrument code to be ready for different date formats, etc…
What is our mission? Perhaps you already know that the collaboration between developers and technical editors / translators is not always harmonic… This is exactly the reason why we want to „Bridge the gap between translation and development“ by offering a new platform where everybody is efficient to do its own work and everybody is happy.
Translation Management: Project progress, analytics, auditing, etc… Over 60% of time saving Continuous Localization: keep translating while development team adds new features to the product InContext editing => context matters Flexible Integration: react.js, angular, vue, i18next, formatjs, polyglot, api, … Risk free: translations can be used by i18next, formatjs or polyglot. Nothing lost. Zero risk. Variable pricing: pay for use. There are no intransparent plans forcing you to pay for stuff you do not need.
Back in 2011 we were in search for an internationalization library allowing to run on frontend (SPA) and backend (node.js). Since we had found nothing useful Jan started to create i18next. i18next goes over just providing the i18n features (plurals, context, interpolation, format) expected. With i18next you can „Learn once - use everywhere“. The community made integrations for frameworks like react.js, angular.js, vue.js and many more. But this is not where it ends...you can use i18next with node.js, php, ios, android and other platforms. I18next reached not only the web, but also mobile and desktop development.
End 2015 the desire of the community to have a localization as a service solution backed by i18next was so big, that we decided to create locize.
When we started with locize we did not know how fast it would scale… serverless means we didn’t need to make that choice. The serverless architecture scales with our business model. Next thing is: we hate maintaining and operating infrastructure. We believe in NoOps (at least traditional Ops). Here serverless saves not only computing power but human resources too. Finally you may ask: Why not PaaS? => We are working with PaaS solutions since early 2011 and we always had the dream to have a platform that does even better. Where you really pay only when something is used (i.e. call of a function, query of a table, etc…) and fully concentrate to the app code. No issues that typically come with distributed systems… etc… And last but not least: serverless is really cool!
AWS is the only ready FaaS provider (and more) that works out of the box and scales like you expected. It’s designed with an API-first approach, so everything can be automated. We think AWS has in mind a possible future where you run functions directly on the edge (directly on hardware). AWS has not only lambda but completes the serverless offering with: API Gateway DynamoDB Simple Storage Service (S3) CloudFront Simple Email Service (SES) etc…
When Developers/Translation Editors/Managers, etc… goes to www.locize.io, the locize-app-client (which is hosted on S3 and exposed by CloudFront) is served. The client then accesses our lambda backend through the API-Gateway also exposed by CloudFront. Our main working storage (DynamoDB) is then accessed by our lambda functions. Each time someone publishes (or auto-publishes) a translation resource a lambda function will save that resource to S3. When published, the endusers of your product can access them via CDN edge locations offered and exposed by CloudFront too.
locize uses 3 different base lambda types. These are not real „AWS-defined“ lambda types but we've defined these types ourself.
The first type is the express type. It defines RESTful APIs using the normal express framework. You see the app.js file looks like a normal express based project. But at the end of the file you see that if this file is executed directly (like „node app.js“) it will start to listen on port 3000 and can be used to test locally. And if required by another file it exports the configured express app. For this scenario there is an additional file lambda.js that uses the help of the npm module „aws-serverless-express“ to proxy and map the lambda function calls to express http requests and responses.
The second type is the async type. This lambda function is triggered by other lambda functions to compute non blocking tasks. i.e. calculation of current words in project, or publishing translation resources to S3, etc… The key element here is that a lambda function is able to call another lambda function by simply using the official aws-sdk npm module. With the help of AWS policies you can define exactly which function can be invoked etc…
The last type is the S3 event type. This lambda function is i.e. triggered by a new CloudFront log file that was saved to s3 (can be enabled on CloudFront). We use this to i.e. calculate the amount of downloads or to generate statistics, etc…
I hope I could give you a little insight into how we use serverless technologies in production. If you have any questions feel free to ask us now or afterwords.
locize tech talk
T E C H
how locize leverages serverless
localization as a service
localization: The process of making a product
suitable for use in a particular country or region.
as a service: easy to use, scale as you grow/
need, hassle-free, collaborative, etc…
WHAT IS LOCIZE?
Bridging the gap between translation and development
As we know how hard it can be to have a solid and working localization process between
developers and technical editors / translators our mission is to offer a new platform where
everybody is efﬁcient to do its own work and everybody is happy.
Often doing correct translations
needs more information by
providing more context information.
The best context is always the
place where the content is shown -
Complete your CI/CD pipeline with
continuous localization! You’re able to
deploy your translation ﬁles separated
from your software so you can update
and manage them independently.
Your web project stays
connected with locize. No
more moving ﬁles around.
Always keeping the overview.
We help you to solve your localization
and translation process, decreasing
development time and cost.
DAY ZERO - HOW ALL BEGAN
All started back in 2011 when we were in
search for an internationalization library that
meets our demand - allowing to run both on
server side node.js and on our client side
single page applications.
Everyone wants his app to be successful, but if that
happens, can it handle the load? Serverless architecture
means you don’t need to make that choice. Scale
technically with your business model!
In terms of both computing power and human resources,
serverless saves. The next level of DevOps is to move
The real PaaS
Most PaaS are not geared towards bringing entire
applications up and down for every request, whereas
FaaS platforms do exactly this.
WHY WE CHOOSE SERVERLESS?
- only ready FaaS provider
- works out of the box
- scales like expected
- API-ﬁrst approach
- lambda future in the edge
AWS integrates like a charm
with other AWS services:
- API Gateway
- Simple Storage Service (S3)
- Simple Email Service (SES)
WHY WE CHOOSE AWS?
THE BASIC SETUP
It integrates very well with S3 (where we serve the localized ﬁles) and with DynamoDB (our
main work storage). We don’t have to worry about scaling, multi-server communication and
other problems related to distributed systems.
- app backend
- web client
We use 3 different lambda types
RESTful APIs using
triggered by other
lambda functions to
compute non blocking
i.e. triggered by a new
CloudFront log ﬁle
that was saved to s3
(i.e. to calculate
If you want to build simple services and run them with AWS Lambda, and you're looking for something low-
overhead, easy to get started with, and you only want to use the node.js runtime, Claudia is a good choice.
works only for node.js,
but it does it really well
It automatically installs templates
to convert parameters and results
consume easily, and makes
developers expect out of the box.
not a framework
It does not abstract away AWS
services, but instead makes them
easier to get started with. Claudia
is not trying to change the way you
structure or run projects.
helps you get simple
stuff done, quickly
There's no need to learn a special
interface syntax, no need to keep your
deﬁnition spread across multiple ﬁles
and introduce the overhead of
coordination and maintenance -- just
write the code to handle requests.
Let’s share some
FEEL FREE TO ASK
Q & A