Find the right developer tools and the companies that use them

Feed
Keep up with the tools you care about
Visit Feed
Stacks
Browse top companies’ stacks
Browse Stacks
Trending
Explore popular and trending tools
Explore Tools
Stackups
Compare tools side-by-side
Compare Tools

See reviews of popular open source and SaaS tools

  • See a personalized feed with the latest reviews and news about your tech stack
  • Share why and how you use tools in front of a community of 250K+ fellow developers
  • Get new product updates, articles, and announcements pushed to you daily/weekly
Check Out the Feed
GitHub
nginx
ESLint
AVA
Semantic UI React
Redux
React
PostgreSQL
ExpressJS
Node.js
FeathersJS
Heroku
Amazon EC2
Kubernetes
Jenkins
Docker Compose
Docker
#Frontend
#Stack
#Backend
#Containers
#Containerized

Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.

We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.

See more
Jeyabalaji Subramanian
Jeyabalaji Subramanian
CTO at FundsCorner · | 2 upvotes · 3K views
atFundsCornerFundsCorner
Dart
Flutter

Recently we were looking for a tool to build cross platform mobile apps. The primary goals for us were two fold:

  1. Ability to rollout the mobile app fast. Being in the FinTech segment, our focus is more on usability & accuracy and less on the flashiness of the app in itself
  2. Our web development team must be able to build the mobile apps. The UI & UX fundamentals are pretty much the same.

With the above in mind, we evaluated React Native, Vue Nativescript and Flutter. While we were able to build fast in all these three choices, we chose Flutter for the following reasons:

Pre-built widgets: All the standard widgets that are required for us to build a functional app were readily available, & required minimal or no tweaking! It was pretty much like cooking up something on the web with Vue & Vuetify, which offer the fastest time frame from code to reality. The key differentiation Flutter offers over it's rivals is the native feel you get on all the widgets. No one can figure out whether it was built in Native android or Flutter.

Availability of Pre-built widgets in Flutter makes it a natural choice for going the fastest from design to reality.

Easy programming constructs & Hot Re-load: The component coding for Flutter is done through Dart. It is kind of a cross between Java & JavaScript. It is easy on the developers. I found asynchronous programming in Dart a breeze! Dart is one of the key reasons why you would build an app in record time with Flutter. Also, you will love the hot reload feature in Flutter, through which you can immediate validate the user interface and interactions.

Hot Re-load is one of the key features that makes development in Flutter a breeze.

Rich set of plugins & great documentation: Flutter eco-system has matured over a period of time. We were able to easily find solutions to various problems & all the plugins worked without breaking anything. For example, we wanted to build a web view for integrating with a Payment link & flutterwebviewplugin was readily available and we were zooming in less than 30 minutes!

With great documentation and eco-system, you are always a plugin or a widget away from completing your functionality!

Great support for Reactive State Management: We were spoilt for choices when we looked at the various options for implementing Reactive statement management. After looking at a number of options, we settled with RxDart and Provider Consumer (Bloc) pattern to implement reactive statement management.

You will be able to apply your hard earned reactive statement management skills in Flutter seamlessly & built beautiful reactive apps.

Easy integration with Android Native SDKs: Flutter provides platform interface to integrate with Native SDKs. Being in the FinTech industry, we were required to integrate with a number of industry standard SDKS for payments & KYC, which were available only in Native. We were to connect with these SDKs and code with ease with the platform interface.

In the end, we were able to build and release an end to end, material design compliant and functionality rich Borrower app within a matter of month and release it for Beta preview! If we had started out

With the announcement of Flutter for Web in this year's google I/O, I think Flutter is going to go big and will shake up the world of cross-platform development.

See more
betocantu93
betocantu93
MySQL
SendGrid
GraphQL
React
React Native
Ember.js
Go
Firebase

Firebase Go Ember.js React Native React GraphQL SendGrid MySQL

Emberjs for our admins panels using ember-apollo and react native using apollo too for our apps, using golang graphql, services like SendGrid to send all the emails, Conekta to for accepting credit cards, firebase for our auth with facebook, google, phone, etc...

See more
Noah Zoschke
Noah Zoschke
Engineering Manager at Segment · | 28 upvotes · 60.1K views
atSegmentSegment
Datadog
TypeScript
Envoy
gRPC
Go
#Observability
#Reliability
#Security
#Json
#REST
#Framework

We just launched the Segment Config API (try it out for yourself here) — a set of public REST APIs that enable you to manage your Segment configuration. Behind the scenes the Config API is built with Go , GRPC and Envoy.

At Segment, we build new services in Go by default. The language is simple so new team members quickly ramp up on a codebase. The tool chain is fast so developers get immediate feedback when they break code, tests or integrations with other systems. The runtime is fast so it performs great at scale.

For the newest round of APIs we adopted the GRPC service #framework.

The Protocol Buffer service definition language makes it easy to design type-safe and consistent APIs, thanks to ecosystem tools like the Google API Design Guide for API standards, uber/prototool for formatting and linting .protos and lyft/protoc-gen-validate for defining field validations, and grpc-gateway for defining REST mapping.

With a well designed .proto, its easy to generate a Go server interface and a TypeScript client, providing type-safe RPC between languages.

For the API gateway and RPC we adopted the Envoy service proxy.

The internet-facing segmentapis.com endpoint is an Envoy front proxy that rate-limits and authenticates every request. It then transcodes a #REST / #JSON request to an upstream GRPC request. The upstream GRPC servers are running an Envoy sidecar configured for Datadog stats.

The result is API #security , #reliability and consistent #observability through Envoy configuration, not code.

We experimented with Swagger service definitions, but the spec is sprawling and the generated clients and server stubs leave a lot to be desired. GRPC and .proto and the Go implementation feels better designed and implemented. Thanks to the GRPC tooling and ecosystem you can generate Swagger from .protos, but it’s effectively impossible to go the other way.

See more
Nick Rockwell
Nick Rockwell
CTO at NY Times · | 23 upvotes · 132.6K views
atThe New York TimesThe New York Times
Apache HTTP Server
Kafka
Node.js
GraphQL
Apollo
React
PHP
MySQL

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

See more

Show your company's entire software stack to thousands of engineers

  • Attract developers by explaining what you use and why
  • Easily reference your software stack by sharing it on job hiring sites
  • Invite your engineering team to contribute to your stack page
Explore Top Stacks

All the best open source, SaaS, and developer tools in one place

  • See what other developers are using
  • Discover new tools submitted by the community
  • Learn why developers like the tools they use
See What's Trending Now