GitHub

GitHub

DevOps / Build, Test, Deploy / Code Collaboration & Version Control

Decision about GitHub, Gatsby, Netlify, styled-components, Redux, React, Firebase, Google, Frontend, ReactRally

Avatar of johnnyxbell
Sr. Software Engineer at StackShare ·

I was building a personal project that I needed to store items in a real time database. I am more comfortable with my Frontend skills than my backend so I didn't want to spend time building out anything in Ruby or Go.

I stumbled on Firebase by #Google, and it was really all I needed. It had realtime data, an area for storing file uploads and best of all for the amount of data I needed it was free!

I built out my application using tools I was familiar with, React for the framework, Redux.js to manage my state across components, and styled-components for the styling.

Now as this was a project I was just working on in my free time for fun I didn't really want to pay for hosting. I did some research and I found Netlify. I had actually seen them at #ReactRally the year before and deployed a Gatsby site to Netlify already.

Netlify was very easy to setup and link to my GitHub account you select a repo and pretty much with very little configuration you have a live site that will deploy every time you push to master.

With the selection of these tools I was able to build out my application, connect it to a realtime database, and deploy to a live environment all with $0 spent.

If you're looking to build out a small app I suggest giving these tools a go as you can get your idea out into the real world for absolutely no cost.

33 upvotes·7 comments·105.9K views

Decision at CircleCI about Amazon S3, GitHub, Redis, PostgreSQL, MongoDB

Avatar of z00b
CTO at CircleCI ·

We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.

As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).

When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.

21 upvotes·1 comment·20.1K views

Decision at Shopify about GitHub, Rails

Avatar of kirs
Production Engineer at Shopify ·

The core Shopify app has remained a Rails monolith, but we also have hundreds of other Rails apps across the organization. These are not microservices, but domain-specific apps: Shipping (talks with various shipping providers), Identity (single sign on across all Shopify stores), and App Store to name a few. Managing a hundred apps and keeping them up to date with security updates can be tough, so we've developed ServicesDB, an internal app that keeps track of all production services and helps developers to make sure that they don't miss anything important.

ServicesDB keeps a checklist for each app: ownership, uptime, logs, on-call rotation, exception reporting, and gem security updates. If there are problems with any of those, ServicesDB opens a GitHub issue and pings owners of the app to ask them to address it. ServicesDB also makes it easy to query the infrastructure and answer questions like, “How many apps are on Rails 4.2? How many apps are using an outdated version of gem X? Which apps are calling this service?”.

19 upvotes·31.9K views

Decision at Quasar Framework about GitHub, Zeit Now, SendinBlue, Vue.js, Node.js, FeathersJS, Quasar Framework

Avatar of nothingismagick

Quasar Framework FeathersJS Node.js Vue.js SendinBlue Zeit Now GitHub

It was almost too easy to build a complete Feathers Rest API combined with Quasar SSR and reactive form that we are serving through an i-frame within our main site for serving our newsletter signup and opt-in page. Total time: 15 hrs. Check it out:

https://quasar.dev/newsletter

19 upvotes·21K views

Decision at Twilio SendGrid about Buildkite, GitHub, InMemoryDatabases, Databases, DataStores, Languages

Avatar of sethgrid
Principal Software Developer at SendGrid ·
BuildkiteBuildkiteGitHubGitHub
#InMemoryDatabases
#Databases
#DataStores
#Languages

When we've gone through code reviews (every code and config change goes through a code review) and feel good about the level of automated testing (no one can sign off on their own code's functionality; a quality assurance engineer or other developer has to verify functionality), we merge our changes via a bot that interacts with GitHub (the bot maintains our versions and change logs). After Buildkite has a green build and our binary is shipped to our repo servers, we are good to roll out deploys to our data centers and to keep pushing the needle on the performance of our system.

#Languages #DataStores #Databases #InMemoryDatabases

18 upvotes·19.1K views

Decision at ChecklyHQ about vuex, Knex.js, PostgreSQL, Amazon S3, AWS Lambda, Vue.js, hapi, Node.js, GitHub, Docker, Heroku

Avatar of tim_nolet
Founder, Engineer & Dishwasher at Checkly ·

Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

Enough biz talk, onto tech. The challenges were:

  • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
  • Update API and back end services to handle and enforce plan limits.
  • Update the UI to kindly state plan limits are in effect on some part of the UI.
  • Update the pricing page to reflect all changes.
  • Keep the actual processing backend, storage and API's as untouched as possible.

In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

  1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
  2. The Vue.js frontend reads these from the vuex store on login.
  3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
  4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

Hope this helps anyone building out their SaaS and is in a similar situation.

17 upvotes·94.4K views

Decision about 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

Avatar of jordandenison

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.

15 upvotes·94.2K views

Decision at ACK Foundry about Bitbucket, GitLab Pages, GitLab CI, GitHub, GitLab, OpenSourceCloud

Avatar of thebadmonkeydev
Senior Software Engineer at StackShare ·

I use GitLab when building side-projects and MVPs. The interface and interactions are close enough to those of GitHub to prevent cognitive switching costs between professional and personal projects hosted on different services.

GitLab also provides a suite of tools including issue/project management, CI/CD with GitLab CI, and validation/landing pages with GitLab Pages. With everything in one place, on an #OpenSourceCloud GitLab makes it easy for me to manage much larger projects on my own, than would be possible with other solutions or tools.

It's petty I know, but I can also read the GitLab code diffs far more easily than diffs on GitHub or Bitbucket...they just look better in my opinion.

14 upvotes·121.1K views

Decision about GitHub, DigitalOcean, Quasar Framework, Vue.js, Laravel

Avatar of realtimeappsolutions
Realtime App Solutions ·

Coming from a non-web development environment background, I was a bit lost a first and bewildered by all the varying tools and platforms, and spent much too long evaluating before eventualy deciding on Laravel as the main core of my development.

But as I started development with Laravel that lead me into discovering Vue.js for creating beautiful front-end components that were easy to configure and extend, so I decided to standardise on Vue.js for most of my front-end development.

During my search for additional Vue.js components, a chance comment in a @laravel forum , led me to discover Quasar Framework initially for it's wide range of in-built components ... but once, I realised that Quasar Framework allowed me to use the same codebase to create apps for SPA, PWA, iOS, Android, and Electron then I was hooked.

So, I'm now using mainly just Quasar Framework for all the front-end, with Laravel providing a backend API service to the Front-end apps.

I'm deploying this all to DigitalOcean droplets via service called Moss.sh which deploys my private GitHub repositories directly to DigitalOcean in realtime.

14 upvotes·12K views

Decision at Zulip about GitLab, GitHub

Avatar of tabbott
Founder at Zulip ·

I have mixed feelings on GitHub as a product and our use of it for the Zulip open source project. On the one hand, I do feel that being on GitHub helps people discover Zulip, because we have enough stars (etc.) that we rank highly among projects on the platform. and there is a definite benefit for lowering barriers to contribution (which is important to us) that GitHub has such a dominant position in terms of what everyone has accounts with.

But even ignoring how one might feel about their new corporate owner (MicroSoft), in a lot of ways GitHub is a bad product for open source projects. Years after the "Dear GitHub" letter, there are still basic gaps in its issue tracker:

  • You can't give someone permission to label/categorize issues without full write access to a project (including ability to merge things to master, post releases, etc.).
  • You can't let anyone with a GitHub account self-assign issues to themselves.
  • Many more similar issues.

It's embarrassing, because I've talked to GitHub product managers at various open source events about these things for 3 years, and they always agree the thing is important, but then nothing ever improves in the Issues product. Maybe the new management at MicroSoft will fix their product management situation, but if not, I imagine we'll eventually do the migration to GitLab.

We have a custom bot project, http://github.com/zulip/zulipbot, to deal with some of these issues where possible, and every other large project we talk to does the same thing, more or less.

13 upvotes·2 comments·106.5K views