T E C H
TALK
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 efficient to do its own work and everybody is happy.
OUR MISSION
InContext Editor
Often doing correct translations
needs more information by
providing more context information.
The best context is always the
place where the content is shown -
your website.
Continuous Localization
Complete your CI/CD pipeline with
continuous localization! You’re able to
deploy your translation files separated
from your software so you can update
and manage them independently.
Flexible Integration
Your web project stays
connected with locize. No
more moving files around.
Always keeping the overview.
SOME BENEFITS
We help you to solve your localization
and translation process, decreasing
development time and cost.
DAY ZERO - HOW ALL BEGAN
2011
2013 2014
2016
2018 2019
2021
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.
?
Enhanced scalability
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!
Lower cost
In terms of both computing power and human resources,
serverless saves. The next level of DevOps is to move
towards NoOps!
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
(and more)
- works out of the box
- scales like expected
- API-first approach
- lambda future in the edge
AWS integrates like a charm
with other AWS services:
- API Gateway
- DynamoDB
- Simple Storage Service (S3)
- CloudFront
- Simple Email Service (SES)
- etc…
WHY WE CHOOSE AWS?
THE BASIC SETUP
It integrates very well with S3 (where we serve the localized files) 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.
JavaScript
everywhere!
Everything is written in JavaScript:
- app backend
- api
- web client
- cli
Full-Stack
JavaScript
express
We use 3 different lambda types
LAMBDA FUNCTIONS
RESTful APIs using
the express
framework
async
triggered by other
lambda functions to
compute non blocking
tasks
s3 event
i.e. triggered by a new
CloudFront log file
that was saved to s3
(i.e. to calculate
downloads)
const express = require('express');
const bodyParser = require('body-parser');
const app = express();
const ensureSettings = require('./lib/ensureSettings');
const verifyApiKey = require('./lib/verifyApiKey');
const missing = require('./routes/missing');
const update = require('./routes/update');
const download = require('./routes/download');
const cors = require('cors');
app.use(cors());
app.use(ensureSettings);
app.use(bodyParser.urlencoded({ limit: '5mb', extended: true }));
app.use(bodyParser.json({ limit: '5mb'}));
app.post('/missing/:projectId/:version/:language/:namespace',
verifyApiKey,
missing
);
app.post('/update/:projectId/:version/:language/:namespace',
verifyApiKey,
update
);
app.get('/download/:projectId/:version?/:language?/:namespace?',
download
);
if (require.main === module) {
// called directly
app.listen(3000);
console.log('lambda started locally on port 3000');
} else {
// required as a module
module.exports = app;
}
app.js
const awsServExp = require('aws-serverless-express');
const app = require('./app');
const server = awsServExp.createServer(app);
exports.handler = (event, context) => {
awsServExp.proxy(server, event, context);
};
lambda.js
updateNamespace.js
const aws = require('aws-sdk');
const lambda = new aws.Lambda({ region: 'eu-west-1' });
// ...
lambda.invoke({
FunctionName: 'locize-async-processing',
// fire and forget; 'RequestResponse' would wait for response
InvocationType: 'Event',
LogType: 'None',
Qualifier: version, // dev or prod or xy
Payload: JSON.stringify({
event: 'namespaceUpdated',
payload: {
projectId: meta.projectId,
version: meta.version,
language: meta.language,
namespace: meta.namespace
}
}, null, 2)
}, (error/*, data*/) => {
// ...
});
async
const AWS = require('aws-sdk');
exports.handler = (event, context) => {
const region = event.Records[0].awsRegion;
const s3 = new AWS.S3({ region: region });
const ddb = new AWS.DynamoDB.DocumentClient({ region: region });
const srcBucket = event.Records[0].s3.bucket.name;
const srcKey = event.Records[0].s3.object.key;
// ...
s3.headObject({
Bucket: srcBucket,
Key: srcKey
}, (err, data) => {
if (err) {
console.error(err);
context.done(null, null);
return;
}
// ...
});
};
index.js
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.
OUR TOOLING
focused
works only for node.js,
but it does it really well
It automatically installs templates
to convert parameters and results
into objects that Javascript can
consume easily, and makes
things work the way Javascript
developers expect out of the box.
no abstraction
deployment utility,
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.
simple
helps you get simple
stuff done, quickly
There's no need to learn a special
interface syntax, no need to keep your
definition spread across multiple files
and introduce the overhead of
coordination and maintenance -- just
write the code to handle requests.
Let’s share some
experience.
FEEL FREE TO ASK
ANYTHING!
locize.com
claudiajs.com
aws.amazon.com/lambda
Q & A
T H A N K
YOU
www.locize.com

locize tech talk

  • 1.
    T E CH TALK how locize leverages serverless
  • 2.
    localization as aservice 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?
  • 3.
    Bridging the gapbetween 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 efficient to do its own work and everybody is happy. OUR MISSION
  • 4.
    InContext Editor Often doingcorrect translations needs more information by providing more context information. The best context is always the place where the content is shown - your website. Continuous Localization Complete your CI/CD pipeline with continuous localization! You’re able to deploy your translation files separated from your software so you can update and manage them independently. Flexible Integration Your web project stays connected with locize. No more moving files around. Always keeping the overview. SOME BENEFITS We help you to solve your localization and translation process, decreasing development time and cost.
  • 5.
    DAY ZERO -HOW ALL BEGAN 2011 2013 2014 2016 2018 2019 2021 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. ?
  • 6.
    Enhanced scalability Everyone wantshis 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! Lower cost In terms of both computing power and human resources, serverless saves. The next level of DevOps is to move towards NoOps! 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?
  • 7.
    - only readyFaaS provider (and more) - works out of the box - scales like expected - API-first approach - lambda future in the edge AWS integrates like a charm with other AWS services: - API Gateway - DynamoDB - Simple Storage Service (S3) - CloudFront - Simple Email Service (SES) - etc… WHY WE CHOOSE AWS?
  • 8.
    THE BASIC SETUP Itintegrates very well with S3 (where we serve the localized files) 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.
  • 9.
    JavaScript everywhere! Everything is writtenin JavaScript: - app backend - api - web client - cli Full-Stack JavaScript
  • 10.
    express We use 3different lambda types LAMBDA FUNCTIONS RESTful APIs using the express framework async triggered by other lambda functions to compute non blocking tasks s3 event i.e. triggered by a new CloudFront log file that was saved to s3 (i.e. to calculate downloads)
  • 11.
    const express =require('express'); const bodyParser = require('body-parser'); const app = express(); const ensureSettings = require('./lib/ensureSettings'); const verifyApiKey = require('./lib/verifyApiKey'); const missing = require('./routes/missing'); const update = require('./routes/update'); const download = require('./routes/download'); const cors = require('cors'); app.use(cors()); app.use(ensureSettings); app.use(bodyParser.urlencoded({ limit: '5mb', extended: true })); app.use(bodyParser.json({ limit: '5mb'})); app.post('/missing/:projectId/:version/:language/:namespace', verifyApiKey, missing ); app.post('/update/:projectId/:version/:language/:namespace', verifyApiKey, update ); app.get('/download/:projectId/:version?/:language?/:namespace?', download ); if (require.main === module) { // called directly app.listen(3000); console.log('lambda started locally on port 3000'); } else { // required as a module module.exports = app; } app.js const awsServExp = require('aws-serverless-express'); const app = require('./app'); const server = awsServExp.createServer(app); exports.handler = (event, context) => { awsServExp.proxy(server, event, context); }; lambda.js
  • 12.
    updateNamespace.js const aws =require('aws-sdk'); const lambda = new aws.Lambda({ region: 'eu-west-1' }); // ... lambda.invoke({ FunctionName: 'locize-async-processing', // fire and forget; 'RequestResponse' would wait for response InvocationType: 'Event', LogType: 'None', Qualifier: version, // dev or prod or xy Payload: JSON.stringify({ event: 'namespaceUpdated', payload: { projectId: meta.projectId, version: meta.version, language: meta.language, namespace: meta.namespace } }, null, 2) }, (error/*, data*/) => { // ... }); async
  • 13.
    const AWS =require('aws-sdk'); exports.handler = (event, context) => { const region = event.Records[0].awsRegion; const s3 = new AWS.S3({ region: region }); const ddb = new AWS.DynamoDB.DocumentClient({ region: region }); const srcBucket = event.Records[0].s3.bucket.name; const srcKey = event.Records[0].s3.object.key; // ... s3.headObject({ Bucket: srcBucket, Key: srcKey }, (err, data) => { if (err) { console.error(err); context.done(null, null); return; } // ... }); }; index.js
  • 14.
    If you wantto 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. OUR TOOLING focused works only for node.js, but it does it really well It automatically installs templates to convert parameters and results into objects that Javascript can consume easily, and makes things work the way Javascript developers expect out of the box. no abstraction deployment utility, 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. simple helps you get simple stuff done, quickly There's no need to learn a special interface syntax, no need to keep your definition spread across multiple files and introduce the overhead of coordination and maintenance -- just write the code to handle requests.
  • 15.
    Let’s share some experience. FEELFREE TO ASK ANYTHING! locize.com claudiajs.com aws.amazon.com/lambda Q & A
  • 16.
    T H AN K YOU www.locize.com

Editor's Notes

  • #2 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.
  • #3 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…
  • #4 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.
  • #5 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.
  • #6 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.
  • #7 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!
  • #8 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…
  • #9 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.
  • #10 locize is a single language solution! Everything is JavaScript! The complete app backend, the api, the cli and other tools runs on node.js… and the locize-app-client is based on React and Redux.
  • #11 locize uses 3 different base lambda types. These are not real „AWS-defined“ lambda types but we've defined these types ourself. The first…
  • #12 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.
  • #13 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…
  • #14 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…
  • #15 Because we have a pure JavaScript landscape we’ve chosen claudia.js It automatically installs and configures a lot on AWS. From API-Gateway to Lambda versioning. Claudia.js does not abstract away AWS services. Really transparent and easy to understand. That’s why our advice is: 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.
  • #16 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.