Feed powered byStream Blue Logo Copy 5Created with Sketch.
Uploadcare

Decision at Uploadcare about PostCSS, Preact, Ember.js, React, Python, Django

Avatar of dmitry-mukhin
PostCSSPostCSS
PreactPreact
Ember.jsEmber.js
ReactReact
PythonPython
DjangoDjango

Simple controls over complex technologies, as we put it, wouldn't be possible without neat UIs for our user areas including start page, dashboard, settings, and docs.

Initially, there was Django. Back in 2011, considering our Python-centric approach, that was the best choice. Later, we realized we needed to iterate on our website more quickly. And this led us to detaching Django from our front end. That was when we decided to build an SPA.

For building user interfaces, we're currently using React as it provided the fastest rendering back when we were building our toolkit. It’s worth mentioning Uploadcare is not a front-end-focused SPA: we aren’t running at high levels of complexity. If it were, we’d go with Ember.js.

However, there's a chance we will shift to the faster Preact, with its motto of using as little code as possible, and because it makes more use of browser APIs. One of our future tasks for our front end is to configure our Webpack bundler to split up the code for different site sections. For styles, we use PostCSS along with its plugins such as cssnano which minifies all the code.

All that allows us to provide a great user experience and quickly implement changes where they are needed with as little code as possible.

19 upvotes·2.2K views

Decision at Uploadcare about AWS Elastic Load Balancing (ELB), Amazon EC2, Python, Tornado

Avatar of dmitry-mukhin
AWS Elastic Load Balancing (ELB)AWS Elastic Load Balancing (ELB)
Amazon EC2Amazon EC2
PythonPython
TornadoTornado

The 350M API requests we handle daily include many processing tasks such as image enhancements, resizing, filtering, face recognition, and GIF to video conversions.

Tornado is the one we currently use and aiohttp is the one we intend to implement in production in the near future. Both tools support handling huge amounts of requests but aiohttp is preferable as it uses asyncio which is Python-native. Since Python is in the heart of our service, we initially used PIL followed by Pillow. We kind of still do. When we figured resizing was the most taxing processing operation, Alex, our engineer, created the fork named Pillow-SIMD and implemented a good number of optimizations into it to make it 15 times faster than ImageMagick

Thanks to the optimizations, Uploadcare now needs six times fewer servers to process images. Here, by servers I also mean separate Amazon EC2 instances handling processing and the first layer of caching. The processing instances are also paired with AWS Elastic Load Balancing (ELB) which helps ingest files to the CDN.

18 upvotes·507 views

Decision at Uploadcare about PostgreSQL, Amazon DynamoDB, Amazon S3, Redis, Python, Google App Engine

Avatar of dmitry-mukhin
PostgreSQLPostgreSQL
Amazon DynamoDBAmazon DynamoDB
Amazon S3Amazon S3
RedisRedis
PythonPython
Google App EngineGoogle App Engine

Uploadcare has built an infinitely scalable infrastructure by leveraging AWS. Building on top of AWS allows us to process 350M daily requests for file uploads, manipulations, and deliveries. When we started in 2011 the only cloud alternative to AWS was Google App Engine which was a no-go for a rather complex solution we wanted to build. We also didn’t want to buy any hardware or use co-locations.

Our stack handles receiving files, communicating with external file sources, managing file storage, managing user and file data, processing files, file caching and delivery, and managing user interface dashboards.

At its core, Uploadcare runs on Python. The Europython 2011 conference in Florence really inspired us, coupled with the fact that it was general enough to solve all of our challenges informed this decision. Additionally we had prior experience working in Python.

We chose to build the main application with Django because of its feature completeness and large footprint within the Python ecosystem.

All the communications within our ecosystem occur via several HTTP APIs, Redis, Amazon S3, and Amazon DynamoDB. We decided on this architecture so that our our system could be scalable in terms of storage and database throughput. This way we only need Django running on top of our database cluster. We use PostgreSQL as our database because it is considered an industry standard when it comes to clustering and scaling.

15 upvotes·634 views

Decision at Uploadcare about Webpack, React, React Storybook, Frontend

Avatar of Zmoki
Frontend Team Lead at Uploadcare ·
WebpackWebpack
ReactReact
React StorybookReact Storybook
#Frontend

React Storybook is one of the most favorite tools in our #Frontend team. When we start a new frontend part, we install storybook at first and create visual React components based on our design with usage stories in Storybook. So, we get a live version of design quickly and can sync with designers before developing of whole app and configure Webpack.

8 upvotes·1.8K views

Decision at Uploadcare about Netlify, Gatsby, React, Node.js, Django, StaticWebHosting, StaticSiteGenerators, Frontend

Avatar of Zmoki
Frontend Team Lead at Uploadcare ·
NetlifyNetlify
GatsbyGatsby
ReactReact
Node.jsNode.js
DjangoDjango
#StaticWebHosting
#StaticSiteGenerators
#Frontend

Since 2011 our frontend was in Django monolith. However, in 2016 we decide to separate #Frontend from Django for independent development and created the custom isomorphic app based on Node.js and React. Now we realized that not need all abilities of the server, and it is sufficient to generate a static site. Gatsby is suitable for our purposes. We can generate HTML from markdown and React views very simply. So, we are updating our frontend to Gatsby now, and maybe we will use Netlify for deployment soon. This will speed up the delivery of new features to production.

#StaticSiteGenerators #StaticWebHosting

7 upvotes·2.2K views

Decision at Uploadcare about Google Hangouts Chat, Webex, Skype, Zoom

Avatar of dmitry-mukhin
Google Hangouts ChatGoogle Hangouts Chat
WebexWebex
SkypeSkype
ZoomZoom

Uploadcare is mostly remote team and we're using video conferencing all the time both for internal team meetings and for external sales, support, interview, etc. calls. I think we've tried every solution there is on the market before we've decided to stop with Zoom.

Tools just plainly don't work (Skype), are painful to install for external participants (Webex and other "enterprise" solutions) can't properly handle 10+ participants calls (Google Hangouts Chat).

Zoom just works. It has all required features and even handles bad connections very graciously. One of the best tool decisions we've ever made :)

6 upvotes·2 comments·256 views

Decision at Uploadcare about Markdown, Slack, slite, Confluence

Avatar of Zmoki
Frontend Team Lead at Uploadcare ·
MarkdownMarkdown
SlackSlack
sliteslite
ConfluenceConfluence

In Uploadcare we like to write internal documentation and instructions for all occasions. We used Confluence before, but strong and very slow UI fall us to frustration. We start to research alternative and met slite. The ability to quickly create notes and search, great onboarding, the familiar interface in Slack style, useful shortcuts, nice code snippets, support of Markdown. Now writing instructions and team notes have become much more pleasant.

4 upvotes·493 views

Decision at Uploadcare about PostCSS, Less, Sass, Frontend

Avatar of Zmoki
Frontend Team Lead at Uploadcare ·
PostCSSPostCSS
LessLess
SassSass
#Frontend

We in our #Frontend team prefer to use the modern and clean syntax of #CSS instead of Sass or Less. On bundle step, we use post-processing by PostCSS to add prefixes, minify code, uploading assets and more. PostCSS get CSS more powerful, it‘s a fantastic tool.

3 upvotes·229 views

Decision at Uploadcare about GitHub Pages, OpenSource

Avatar of Zmoki
Frontend Team Lead at Uploadcare ·
GitHub PagesGitHub Pages
#OpenSource

We have many #OpenSource libraries. Some of them need a demo besides documentation. We use GitHub Pages for a demo of libraries. We create a demo folder near with code of the library, add index.html with demo code and publish files only from demo folder to gh-pages. Fast and simple.

3 upvotes·222 views

Decision at Uploadcare about Stylelint, ESLint, Markdown, JavaScript

Avatar of Zmoki
Frontend Team Lead at Uploadcare ·
StylelintStylelint
ESLintESLint
#Markdown
#JavaScript

To avoid code formatting conflicts and keep a high quality of code we use linters. ESLint for #JavaScript, Stylelint for #CSS, remark-lint for #markdown. Good point that tools allow using shareable config, it useful cause we have many projects.

3 upvotes·105 views