From ColdFusion to GraphQL: Rapidly Refactoring A Legacy Application

SightBox builds a complex application using ColdFusion. Over time this became hard to maintain and extend. That led the team to investigate serverless solutions. With AWS AppSync, AWS Lambda, Amazon Aurora Serverless, and many other serverless services and tooling provided by Stackery, they learned how to rapidly refactor our application into a modern, efficient GraphQL service.

Transcript

1. From Coldfusion To GraphQL: Rapidly Refactoring A Legacy Application 1
2. Tory Adams Full Stack Engineer, Sightbox 6siiix 2
3. About Sightbox Sightbox is a new way for contact lense wearers to experience vision care. For an annual membership, we simplify the vision care experience by booking and paying for annual eye exams, managing prescriptions, and sending a yearly supply of contact lenses directly to our members’ door. 3
4. Background • I fell in love with computers at a very young age • Helped a team connect a car to the internet • My first program was a calculator for algebra 4
5. Where we Started Giant Database Single On-Site Server 5
6. Over 200K lines of code 6
7. Why is this a problem? • Ownership • New Features • Scaling • Deployments 7
8. What Now? 8
9. Option 1 Rewrite 9
10. Option 2 Weave new features in with the legacy code 10
11. Option 3 Strangler Pattern 11
12. • Clear Boundaries • Makes new feature development easier • Can ship features sooner rather than later 12
13. Tools we chose: 13
14. Serverless is exciting, but the reality is complex 14
15. Tools we chose: 15
16. Stackery automates operations so you can focus on products and scale teams 16
17. Know what versions are deployed across all dev, test, production environments, accounts and regions 17
18. Troubleshoot and observe the components of your services with ease. 18
19. Tools we chose: Appsync Lambda 19
20. GraphQL out of the box is a monolith 20
21. Questions: Clear Boundaries for team ownership? Multi-Service Schema Design? Re-use of GraphQL Resolvers ? 21
22. Clear Boundaries for team ownership 22
23. • Clear Boundaries • Isolation of data • Organization of resolvers • Multiple stacks allowing for faster development Blackbox GraphQL 23
24. Isolate AppSync to its own stack Where to start 24
25. How do we do this 25
26. Cross Stack Communication • Exports are great for sharing resources across stacks. • This allows us to separate services and define boundaries 26
27. Consuming a shared resource Import the CloudFormation export and you are ready to go. 27
28. Multi Service GraphQL Schema 28
29. AppSync only allows for one file 29
30. • Bloated • Hard to navigate • Git conflicts are a problem GraphQL Schema Design 30
31. • Allows for any folder structure (schema -> team -> service -> file.gql) • Compiled single file only at deploy time • Ownership is easy • Git Conflicts are easier to solve Multiple Files 31
32. Reusing existing AppSync Resolvers 32
33. What is an AppSync Resolver A Resolver is a collection of functions that generate a response for a GraphQL query or mutation. 33
34. User.Posts is the same as Query.getPostsByUserId v v Re-use Resolvers 34
35. Option 1 Move all code to consumable package 35
36. Option 2 Leverage Velocity Templates 36
37. Leverage Velocity Templates A velocity templates is a layer between the GraphQL request and your data store (DynamoDB, Lambda, Http, Sql) 37
38. How they work 38 Request comes in, the request template is invoked, it formats a request to the data store. Once the data store responds the response template is invoked and formats the response for the client.
39. User.Posts is the same as Query.getPostsByUserId Re-use Resolvers 39 v v
40. In GraphQL the only data returned to the request, is the data that is requested and defined in the schema Data Design 40
41. Template Design • “$context.arguments” accounts for query or mutation requests • “$context.source” accounts for nested resolvers 41
42. • Use existing data source previously defined for the query • Use existing templates defined for the top level query • The only change is on TypeName and FieldName YAML Design 42
43. • Clear Boundaries for team by separating resolvers • Multi file schema to define clear boundaries and contracts between teams. • Re-use of resolvers to cut down on duplicate resources and code Blackbox GraphQL Recap 43
44. Databases 44
45. • Over 140 tables • Over 200 columns on single tables • Ad-hoc database design • Hosted on-site Where we started 45
46. Migrating to a new database 46
47. Converter Solution • Cron Jobs to migrate data • Not immediate • Hard to determine where in the conversion process you are 47
48. • Only the GraphQL schema is designed for how you want your data to be. • Masks the problem, doesn’t solve it. Abstracted Strangling Method 48
49. Strangler Pattern for DB • Follows the same pattern as code • Writes to both legacy and new data stores • Backwards compatible • Allows for incremental improvements • New features use the new data store. 49
50. Tools we chose: Appsync Lambda DynamoDB 50
51. DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. It has some upsides as well as some downsides. 51
52. Pros • Great Scaling • Fast • Dependable • Schema-less • Can be a cheap solution 52
53. Cons • Schema-less • Querying • Advanced Relationships • Eventually Consistent Reads 53
54. Tools we chose: Appsync Lambda DynamoDB Serverless Aurora 54
55. Amazon Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora (MySQL-compatible and PostgreSQL-compatible editions), where the database will automatically start up, shut down, and scale capacity up or down based on your application's needs. 55
56. Pros 56 • Easy (ish) Setup in CFN
57. Cloudformation Serverless Aurora 57
58. Stackery Serverless Aurora Add a resource > drag a resource inside of your VPC > fill out some values in the configuration screen > done. 58
59. Pros • Easy (ish) Setup in CFN • Maintenance windows no more • Better security out of the gate • Data API 59
60. Cons • Scaling is slow and effects your connection pool size • Cold Starts • Leaving it running all the time is not cost effective • Data Migrations are hard • Coordination of schemas across teams 60
61. That was our journey 61
62. How to begin your journey 62
63. Service Provider 63
64. Infrastructure as code 64
65. A Feature • Start small; A single function • Start with a single stack • I recommend a single read query • Have fun! 65
66. Remember @BiIIMurray Parody Account Any pizza can be a personal pizza as long as you try hard enough and believe in yourself 66
67. 6siiix 67