Did you hear about Ember’s FastBoot? What about Vue 2.0? Falcor, service workers in Angular, React Native? The hack and learn developer in me wants to try them all, and the 1,000 other things the JS community will release this week.
Alas, I have products, I have a team, I have stakeholders and a steady income stream to protect.
Sometimes being established is no fun.
At NewSpring Church we have grown a lot over the past 15 years. Like any organization that goes through explosive growth, we hacked and patched and duck-taped as many third party and in house systems together as we could to solve our problems. At the start of this year, we had data all over the web with different vendors but our people can’t see what campus they attend and their giving history in one place. We have too large of an application stack to pivot everything at once, but we need to be able to give our people one place to go to find us online. We needed a solution, and one that would serve us for the next 15 years.
Enter GraphQL, stage left
If you haven’t heard of GraphQL, it is an application query language which allows client side applications to get the data they want. More importantly, it is a way to query multiple data sources from a single endpoint, so your MEAN, LAMP, or PARTYPARROT stacks are no longer limited to the database they were initially designed around.
This year we moved off of multiple exterior venders in favor of a .NET and MSSQL app called Rock that we helped to build. We use Expression Engine (a PHP and MySQL CMS) to power the content for our 15 sites and apps and have a dwindling list of third party vendors like MailChimp and Google Site Search that we use. Our new applications and sites are built using Meteor (which we love) and have a Mongo backend. Thanks to GraphQL, our users can access data from all of these stacks in a single place. The query shown below merges data from MSSQL (the personal info), gets what this person has liked in our app from Mongo, and pulls content about those liked items from MySQL.
This image represents data from 3 different databases, managed by three different applications, and returned in a single request.
One of the best ways to work with GraphQL is using the Apollo data stack. It has a great client library with some awesome (and growing) features, some killer dev tooling, and making a server with Apollo is way easier and less boilerplate than typical GraphQL servers. When we started our journey into GraphQL it didn’t exist and I wish it would have.
Giving in the 21st century
One of the first pieces of our old conglomerate stack to get the axe was our giving platform. If you wanted recurring giving or an account, you would go to a clunky third party, and if you just wanted to give quickly, you go to an in house app that was limited in features. So we built a new app:
We wanted to use the Meteor accounts system and reactive data, get financial accounts, show giving history, and show profile info from Rock, have all of our images and content stored in our CMS, and we wanted in-app search using Google’s site search API.
That sentence is just as exhausting as it would’ve been to build those endpoints using REST
Using the power of GraphQL, in one week a single developer was able to connect all of those databases and systems together into a single endpoint. In one week our application tripled its speed, our potential app server load decreased, and our developers got their hands on some of the best tooling around data we have ever used.
Last year we took in over $64,000,000, and around 70% of that came in through our online applications. We have a few hundred employees, maintain 15 locations, and have around 33,000 people a week walk through our doors. Online we had over 3.5 million people visit us last year. We are not a startup. Whatever choice we made in how to handle our data had to provide the security and reliability to keep the lights on and set us up for future success. GraphQL is that choice. Innovation in one of our product areas is now accessible in all of our applications. With GraphQL, we can build our products around our features rather than around our stack.
Apollo and the modern data stack
Everything I have written about above is the reason why NewSpring Web contributes to the Apollo project. From startup to enterprise, it will make your application better and your developers happier.
Special thanks to Sashko Stubailo, Jonas Helfer, and matt debergalis for welcoming our rag tag band of developers into their code base; to Jon Edmiston, David Stevens, and David Turner for making the best management app ever with Rock; and a heartfelt shout out to John Pinkerton for introducing me to Meteor in the first place.
James Baxley III
Normally found on his farm working his bee hives or tending his flock of sheep, James is a believer in cultivating happy and healthly communities. He is a lover of design systems, roses, and fixing old land rovers.
Stay in our orbit!
Become an Apollo insider and get first access to new features, best practices, and community events. Oh, and no junk mail. Ever.
Make this article better!
Was this post helpful? Have suggestions? Consider so we can improve it for future readers ✨.