# Making Meetup - Medium We're here to make Meetup. - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Scaling GraphQL development at Meetup DevFeed: [Scaling GraphQL development at Meetup]() Original publisher: [Read original article]() Author: Doug Tangren Published: 2024-02-05T22:11:32Z Content type: article Language: en Sources: [Making Meetup - Medium]() Topics: [GraphQL](), [Development](), [maintenance]() Tags: [annotation-processor](), [code](), [development](), [graphql](), [java](), [maintenance](), [testing]() ### AI overview Meetup describes how it scaled GraphQL development by reducing maintenance and turnaround time for common GraphQL changes. The article examines GraphQL Java's DataFetcher and TypeRuntimeWiring model, and explains how repetitive schema wiring and file organization created complexity and testing difficulties. ### Source excerpt Photo by Alev Takil on Unsplash At Meetup we're invested a great deal of our products technical strategy in GraphQL. For our core product API's we lean heavily on GraphQL Java for exactly that. Scaling can be defined in several ways. Typically people talk about scaling out servers to handle request load. In this post I'll take about scaling (in) development time, through the lens of reducing load placed on developers so they can make better use of their time. Over the years we've evolved our practices to optimize for reducing maintenance and faster turn around time for common GraphQL-oriented changes. This post outlines our current practices based on what we've learned. To start off, it's useful to introduce the vocabulary of GraphQL Java. A DataFetcher is the interface through which you fetch data for a given field or set of fields that a GraphQL client selects. GraphQL Java invokes these when a client selects their associated field based on a TypeRuntimeWiring which is what binds your code to your GraphQL schema. To some degree you can think of this like AWS Lambda where the trigger integration is GraphQL Java and your functions are DataFetchers. In fact we're not the first to think of that analogy . In our humble beginnings we started out with an approach that looked similar to the hello world example in the GraphQL docs: a single class with multiple runtime type wirings for various fields. This quickly grew unwieldy so we split that into multiple files which represented types and all of their respective fields. This worked for a while, but not before a few less than obvious issues started to creep in. Exposing a field meant writing the code that fetched the field's data and also the code required to wire that into the schema, and that became onerous. The latter was very repetitive, sometimes error prone, and the file that contained that grew slowly but surely into the same shape as our initial approach over time. It surfaced as nonessential complexity to new eng ## Getting your GitHub Actions AWS security posture straightened out with OIDC DevFeed: [Getting your GitHub Actions AWS security posture straightened out with OIDC]() Original publisher: [Read original article]() Author: Doug Tangren Published: 2024-01-22T14:42:26Z Content type: tutorial Language: en Sources: [Making Meetup - Medium]() Topics: [GitHub Actions](), [OpenID connect (OIDC)](), [Amazon Web Services](), [Security](), [Automation](), [AWS IAM]() Tags: [automation](), [aws](), [command-line](), [credentials](), [github](), [github-actions](), [hardening](), [oidc](), [security]() ### AI overview This tutorial explains how Meetup uses OpenID Connect to authenticate GitHub Actions workflows with AWS instead of storing static AWS credentials. It describes provisioning an OIDC provider and IAM roles with an AWS SAM template, establishing trust between GitHub and an AWS account, and configuring role permissions for each repository. ### Source excerpt Photo by Roman Synkevych on Unsplash Without a doubt at this point everyone should be deploying their AWS infrastructure through some form of automation. Tools to do so are both numerous and ubiquitous. At Meetup, we use GitHub Actions as a workflow automation tool and AWS SAM CLI to deploy the majority of our AWS infrastructure defined within templates. Because you're giving machines the power to both hoist and tear down you're sails it's behooving to be mindful of the security guardrails you've set up to minimize what could possibly go wrong were those to fall into the wrong hands. Using a common but native approach authenticate with AWS from your GitHub Actions workflow like storing static AWS credentials within GitHub Actions opens the door to leaking access in one way or another which others can exploit. AWS actually has a recommendation on this and that is to use OIDC instead. This is also a recommendation of GitHub themselves. We'd like to share our recipe for how we manage our AWS infrastructure management automation securely. While you can read more about how OIDC works here, I'll spare the details in this post to focus instead on the steps you can take to bootstrap your own setup so you can get off to the races quickly. First you'll need to provision a few AWS resources that define and grant a trust model between your AWS account and GitHub's servers. Below is a SAM template to do just that. AWSTemplateFormatVersion: "2010-09-09" Parameters: Repository: Type: String #👇 OIDCProvider's are account level and there can be only one per URL but you may choose to provision more than one role for each GH repo CreateProvider: Type: String Default: "true" AllowedValues: - "true" - "false" Conditions: ShouldCreateProvider: !Equals - !Ref CreateProvider - "true" # https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services Resources: # 👇 create an OIDCProvider usedto trust GitHub's servers # https ## Securing front doors by signing standard requests with the AWS SDK v2 DevFeed: [Securing front doors by signing standard requests with the AWS SDK v2]() Original publisher: [Read original article]() Author: Doug Tangren Published: 2024-01-19T19:52:03Z Content type: tutorial Language: en Sources: [Making Meetup - Medium]() Topics: [Amazon Web Services](), [AWS IAM](), [Java](), [SDKs](), [Java HttpClient](), [Security](), [HTTP](), [AWS Lambda]() Tags: [api](), [api-management](), [aws](), [aws-lambda](), [http](), [iam](), [java](), [sdk](), [security]() ### AI overview This tutorial explains how to sign standard Java HttpClient requests with AWS Signature Version 4 using the AWS SDK v2. It describes authenticating requests with IAM credentials and includes an AWS SAM example for protecting Lambda Function URLs with AWS_IAM authentication. ### Source excerpt Photo by Masaaki Komori on Unsplash Security is not an optional feature when designing networked services, especially those accessible over the internet. It's a given. For this reason secure services must be authenticated. There are an innumerable ways to solve this problem in the technology space. Fortunately for AWS customers, this is a wheel that needs no reinventing. There is a solution for this with AWS and it's called sig v4 signing: a specification for authenticating a HTTP requests with IAM credentials in a way that AWS services can then validate them before providing access to your services capabilities. Sig v4 is such a common a feature for securing your AWS infrastructure that in many cases it's almost as easy as a one line change to your infrastructure definition to add it. Here's an example of adding sig v4 auth protection to your AWS Lambda Function URLs in a sam template for illustration. AWSTemplateFormatVersion: "2010-09-09" Transform: AWS::Serverless-2016-10-31 Resources: CoolApi: Type: AWS::Serverless::Function Properties: # 👇 give your function a Http API URL FunctionUrlConfig: # 👇 yes, it's that easy AuthType: AWS_IAM # ... the rest As AWS customers, Meetup uses sig v4 auth to secure a number of our own services. This implies we need clients which are able to sign requests to make any use of them. In this post I'd like to share our recipe to doing so by using what you likely already have in your kitchen cabinets: the AWS SDK that's likely already on your class path as well as the Java standard library HttpClient which requires no additional external dependencies. Below is a full example of a utility, sans javadocs and wildcarded imports for brevity which fits neatly into a single file which allows you to securely sign std lib HTTP requests used with the std lib HttpClient using AWS's Aws4Signer which uses it's own representation of HTTP requests. package com.meetup.sigv4.jdk; import static java.net.http.HttpRequest.BodyPublishers; import static ## Comparing the Dependency Size of AWS Java SDK v1 and v2 SQS Clients DevFeed: [Comparing the Dependency Size of AWS Java SDK v1 and v2 SQS Clients]() Original publisher: [Read original article]() Author: Doug Tangren Published: 2024-01-19T16:40:54Z Content type: article Language: en Sources: [Making Meetup - Medium]() Topics: [Java](), [Amazon Web Services](), [SDKs](), [Amazon Simple Queue Service (SQS)](), [Netty](), [Gradle](), [Architecture & Design]() Tags: [aws](), [dependencies](), [dependency-management](), [gradle](), [java](), [maintenance](), [sdk](), [sdks](), [security-vulnerabilities](), [sqs]() ### AI overview This article from Meetup compares the dependency size of AWS SDK for Java v1 and v2 using SQS client versions 1.12.637 and 2.23.3. It attributes the larger v2 footprint largely to bundled defaults and transitive dependencies, including Netty, and discusses the maintenance and security costs of dependencies. ### Source excerpt Photo by Nathan Dumlao on Unsplash At Meetup, two of our core engineering principles are to be cost conscious and use technologies that are proven to scale. On Meetup every time you click an attend button, schedule an event, create a group, start a conversation, decide join the local puppy group in your neighborhood, or any other activity your request is guaranteed to pass through multiple JVMs and within those, likely half a dozen AWS services along the way which themselves are often sitting in front of multiple JVMs. Both the JVM and AWS APIs are considered proven, rock-solid, and scalable technologies at Meetup. This is why we're heavily invested in Java and AWS for our core platform services as well as keeping both up to date. Like many companies, AWS included, we've completed the spiritual journey of migrating our largest primary platform codebase from Java 8 to 11, then to 17, and most recently to 21. The renaissance happening with the Java community has been wonderful and has unlocked a number of options for us, one being the subject of this post. Being a 20 year strong engineering focused company, we've accumulated a lot learnings in the area of understanding the cost of code dependencies. We've learned it's much easier to add than to remove dependencies and that the simplest solution to avoid the future burden of maintenance tax and security vulnerabilities attached to dependencies is simply not to invite them to the party in the first place so we're relatively conservative when evaluating new dependencies. We understand the long term tax and cost involved in doing so. When evaluating the new v2 AWS SDKs for Java, the first surprise we encountered was that it was nearing twice the size of that of the equivalent v1 SDK clients. While we started our V2 migration journey relatively long ago we recently revisited and this is still more or less the same case. We'll compare the AWS SDK SQS client versionsv1.12.637vs v2.23.3 respectively in this post. Here is an e ## How Meetup Used Android Baseline Profiles to Reduce Cold Startup Time by 36% DevFeed: [How Meetup Used Android Baseline Profiles to Reduce Cold Startup Time by 36%]() Original publisher: [Read original article]() Author: Colin Lee Published: 2023-07-19T19:26:13Z Content type: article Language: en Sources: [Making Meetup - Medium]() Topics: [Android](), [Mobile](), [Benchmark](), [App](), [Google](), [Refactoring]() Tags: [android](), [android-app-development](), [app-development](), [app-performance](), [app-startup](), [benchmark](), [google](), [google-i-o](), [meetup](), [mobile](), [mobile-app-development](), [mobile-app-performance](), [performance](), [pixel](), [refactoring]() ### AI overview Meetup integrated Android baseline profiles into its main app and measured a 36% improvement in best-case cold startup time on a Pixel 3, from 970ms to 620ms. The article explains that baseline profiles let the JVM pre-compile functions before they are needed, while noting that the business impact on conversion, retention, and revenue was not established. ### Source excerpt As consumers, we've all been there -- you download a new app, launch it for the first time, and are frustrated by how long it takes to start up. If an app is sluggish at first launch, it leaves a bad first impression that's hard to overcome. At Meetup, we realized having slower apps was likely costing us users and revenue. So we implemented a simple change that cut our app's startup time by 36%, delivering a smoother experience that helps us to convert and retain users. And -- we did it without even writing much code. The Meetup mobile app, which now uses baseline profiles to start up to 36% faster Here's how we did it. Google recently introduced a technology called baseline profiles that optimizes Android apps for faster launch times. It allows the Java Virtual Machine (JVM) to pre-compile functions so they're ready before they're needed. As soon as it was announced at Google I/O 2022, I began adding baseline profiles to Meetup's Android apps. Recently, I conducted a benchmark test to measure the impact. The results were astounding. We integrated baseline profiles into our main Meetup Android app and saw best case cold app startup times on a Pixel 3 drop from 970ms to 620ms -- a 36% improvement. For app performance, a 36% improvement is remarkable. On a large refactoring initiative at a previous company, we were only able to achieve a 10% improvement in performance. Easy performance wins like baseline profiles don't come across your desk every day. This is what a baseline profile actually looks like before it is converted into binary For a more detailed understanding of baseline profiles, I recommend watching the Google video below. The takeaway for any mobile app business is clear. Your app startup experience shapes lasting first impressions. Is your app fast and friction-less or sluggish and buggy? Investing in performance optimizations like baseline profiles can deliver a big competitive advantage by creating smoother first-time user experiences. The result is high ## Lessons Learned with Jetpack Compose DevFeed: [Lessons Learned with Jetpack Compose]() Original publisher: [Read original article]() Author: Joe Williams Published: 2023-05-12T15:44:18Z Content type: tutorial Language: en Sources: [Making Meetup - Medium]() Topics: [Jetpack Compose](), [ui](), [Android](), [XML](), [Android Studio]() Tags: [android](), [android-studio](), [compose-ui](), [declarative](), [jetpack-compose](), [meetup](), [swiftui](), [view-binding]() ### AI overview This developer article shares Meetup's experience adopting Jetpack Compose alongside SwiftUI and integrating Compose into an existing Android app. It explains the benefits of declarative UI, including faster UI development and simpler component reuse, while discussing the transition from XML layouts and view binding. It also covers Compose previews, Live Edit, and ComposeView and AndroidView for integration with traditional layouts. ### Source excerpt Photo by Brett Jordan on Unsplash At Meetup, we are all-in on declarative UI. Our Organizer app was built from the ground up with Jetpack Compose and SwiftUI. We like it so much we've been integrating it into our existing Meetup app whenever possible. That road has not always been a smooth one, though, and we'd like to share some of what we've learned on that journey. Making the switch is worth it No doubt, some developers are hesitant to pick up yet another newly emerging Android technology. I certainly was. It's tempting to stay in the comfort of XML layouts and view binding. But wouldn't it be nice to create a screen with just one file? Do you really want to keep filling in boilerplate code for RecyclerViews and Adapters? We found that once everyone is on the same page with Compose, UI development speeds up significantly. Reusing a UI component is now just a matter of writing the declaration for it. No more extending a view, dropping it into an XML file, and then hooking up the backing code. Set up previews and use Live Edit When switching from XML layouts to Compose, the first downside that may jump out at developers is one of previewing the UI. For standard XML, changes made are reflected immediately in the design view, while Compose requires the app to be built. There are two things that can help alleviate this problem: Previews and the Live Edit feature. Declaring previews allows you to see how your composables will look in a running app. This is especially useful for commonly used elements. For instance, we have a MeetupButton that gets used across both of our apps, so having previews of each version of it helps us quickly identify which one to use when we're building a screen. Previews also make it easy to test layouts without repeatedly running your application and simulating states: Alongside previews, Live Edit lets you make changes to your composables while the app is running and see those changes immediately. Simply deploy your app from Android Studio ## Announcing Markdown Twain: A new, Open Source Markdown editor DevFeed: [Announcing Markdown Twain: A new, Open Source Markdown editor]() Original publisher: [Read original article]() Author: Colin Lee Published: 2023-04-26T18:52:58Z Content type: release Language: en Sources: [Making Meetup - Medium]() Topics: [Markdown](), [Android](), [Jetpack Compose](), [Open Source](), [Library](), [Syntax Highlighting]() Tags: [android](), [compose](), [jetpack-compose](), [library](), [markdown](), [open-source](), [syntax-highlighting]() ### AI overview Meetup announces Markdown Twain, an open-source Android library built with Jetpack Compose that provides Markdown editing and viewing components. It supports syntax highlighting, real-time previews, customizable styling, and Apache 2.0 licensing. ### Source excerpt We at Meetup are excited to announce the release of Markdown Twain, an open-source library for Android that provides an easy-to-use syntax highlighting editor and viewer for Markdown text using Jetpack Compose for Android. Our new Meetup for Organizers app was entirely written in Jetpack Compose and Kotlin Multiplatform Mobile. While building the new app, we needed a Markdown editor to allow Meetup organizers to edit rich text descriptions for the events they manage. We discovered that no Markdown Editor already existed for Jetpack Compose. So we wrote our own. Editing an event description in Meetup for Organizers on Android With Markdown Twain, developers can easily add a Markdown editor and viewer to their Android applications, allowing people using their apps to easily format and style their text with Markdown syntax. Markdown Twain offers a number of features, including syntax highlighting for Markdown text, real-time preview of formatted text, easy-to-use editor and viewer components, and customizable styling options, and it is based on the popular Markwon library for Android Views. Check out a demo video to see Markdown Twain in action: https://medium.com/media/6c6361c4e125795538792e9238068ac1/href To use Markdown Twain in your Android project, simply follow these steps: Add the following dependency to your app's build.gradle.kts or build.gradle file: dependencies { implementation("com.meetup:twain:0.2.2") // or the latest version } Use the MarkdownEditor() or MarkdownText() Composables in your Jetpack Compose layouts. There are extra attributes available for customizing the display. val textFieldValue = rememberSaveable(stateSaver = TextFieldValue.Saver) { mutableStateOf("") } Card { MarkdownEditor( value = textFieldValue.value, onValueChange = { value -> textFieldValue.value = value.copy(text = value.text) }, modifier = Modifier.fillMaxWidth() ) }MarkdownText( markdown = textFieldValue.value.text, modifier = Modifier.fillMaxWidth() ) Markdown Twain is licens ## Effective ways to contribute in a new codebase as an onboarding iOS Engineer DevFeed: [Effective ways to contribute in a new codebase as an onboarding iOS Engineer]() Original publisher: [Read original article]() Author: Hakeem Musse Published: 2023-04-11T20:35:32Z Content type: tutorial Language: en Sources: [Making Meetup - Medium]() Topics: [iOS](), [Documentation](), [implementation](), [Xcode](), [Code](), [legacy](), [A/B Testing](), [Framework]() Tags: [a-b-testing](), [code](), [dependencies](), [documentation](), [engineering](), [ios](), [legacy-code](), [mobile](), [onboarding](), [tips](), [xcode]() ### AI overview An iOS engineer at Meetup shares onboarding practices for contributing to an existing codebase. Using the re-platforming of an A/B testing Experiment feature as an example, the article emphasizes reading documentation, understanding architecture and dependencies, and resolving issues when modularizing legacy code. ### Source excerpt Photo by Aron Visuals on Unsplash For most engineers, joining a new organization means having to onboard to some existing codebase. The larger a codebase, the more complicated it can be to navigate for new engineers, which can be overwhelming to start contributing code. As an iOS Engineer at Meetup, I experienced this firsthand when onboarding. This blog post focuses on some tips I've learned from my experiences contributing to Meetup's iOS codebase when I first onboarded. To illustrate these practices, let's look at an example of a task I worked on. The task My task was to re-platform our Experiment feature in the iOS app, which allows us to conduct A/B testing on new features. At the time, this feature was located in Meetup's legacy codebase and part of the task was to move this code into its own module. The acceptance criteria for this task was to make it so any engineer can import the standalone feature and use it without having to reference legacy code. When I began this task, I had some knowledge of where I can start working, so like any eager engineer, I dove right in! On the surface, re-platforming is essentially moving over files and implementation to a modularized framework. I thought, "how hard can this be, right?" I started ⌘+ C'ing like never before! Files were being copied at the speed of light. We were taking flight! I couldn't wait for the reaction of my peers: "Damn, Hakeem, you did this that quickly?" However, not too far into the work, I was hit with about 100+ Xcode errors when trying to compile. I could faintly hear Xcode laughing at me. This leads me to tip number one... Reading Documentation This underestimation was a sign for me that I had to go back to square one and read up on how this feature is architected. Indeed, reading the documentation unveiled nuggets of information on how to re-platform that I didn't realize. More importantly, reading documentation gave a high level picture of how individual components work together. So, I tried agai ## I know Nothing in Kotlin DevFeed: [I know Nothing in Kotlin]() Original publisher: [Read original article]() Author: Colin Lee Published: 2022-09-16T15:32:41Z Content type: tutorial Language: en Sources: [Making Meetup - Medium]() Topics: [Kotlin](), [Exception](), [multiplatform](), [Coroutines](), [iOS](), [Swift]() Tags: [coroutines](), [dns](), [exception](), [exception-handling](), [ios](), [kotlin](), [kotlin-multiplatform-mobile](), [network](), [nothing](), [refactor](), [swift](), [timeout]() ### AI overview This article explains Kotlin's Nothing type through a code-pairing example involving repository calls in a shared Kotlin Multiplatform Mobile module. It describes refactoring repeated exception handling, rethrowing CancellationExceptions for cooperative coroutine cancellation, and using Nothing for functions that always throw. ### Source excerpt When the Greek philosopher Socrates professed that "I know only one thing -- that I know nothing," he wasn't exactly professing ignorance. It was an ancient formulation of the Dunning-Kruger effect. He had discovered that the more he learned, the wider the expanse of human knowledge seemed and the less that it seemed he knew. A fool, on the other hand, might believe that they're "not smart, but genius... and a very stable genius at that," and that they know "only the best words." In this sense, it's a good thing to know nothing. It's also true in Kotlin. During a recent code pairing session, I discovered that in Kotlin, there are numerous developers who have written code in the language for many years. And yet, they still don't know Nothing. Our pairing session became a big fuss about Nothing. We were working on some Repository code in our shared Kotlin Multiplatform Mobile (KMM) module of our Meetup for Organizers app. In this code, there was a repeated block at the end of every repository call to handle network, DNS, and timeout errors. We decided it would make sense to refactor this block into a function as we used it so often. The repeated block in question handled a catch block. It had to re-throw any CancellationExceptions to allow cooperative cancellation of coroutines. Then we had to wrap any other exception and re-throw it as a custom exception type so that we can easily tell iOS a complete list of all types we intend to throw in a @Throws declaration. This allows exception handling and avoids crashing when our functions are called by Swift code. In essence, this code block always threw an Exception. The pairing session became quite funny, like the Laurel and Hardy "Who's on First" comedy routine, but you could tell there was Nothing more frustrating, too. It went something like this: "Why am I getting this red text at the call site?" "The return type is incorrect because you always throw an exception. You need to return Nothing." "I already am returning nothi