General

Building a Multi Platform Community Engagement Tool

Published Apr 8, 2021

Updated Jan 31, 2023

6 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Intro

We’re building a community forum for our consumers to discuss our products here at A Latte Java. This is going to be a new greenfield project that is a companion app to our ecommerce site. Our team has determined that we really need both desktop and mobile presences and need to get a MVP to market in the next 3 months so we’re on a relatively tight timeline.

For this, we’re starting with just the basic product idea and are having our first round table discussion to think through the requirements and identify options for creating our solution. The only requirements from the business is to generate a space where people can safely discuss how they use our products and share their how-to guides.

Mobile & Desktop

When we said we needed both mobile and desktop presences, what are some of the options to get us there? Do we have to build a website and a mobile application? Are there ways to share or reuse code across the different platforms?

Hybrid apps and PWAs are a few solutions that can get us to the solution that we're seeking. Hybrid apps let us use tools like React Native or Ionic to use web technology we're familiar with and compile it to native app code.

One of my first thoughts would be to create some kind of a hybrid app so people can comment on the go as they feel like it. Maybe they want to snap a picture of their coffee as they're brewing it in the morning or take a quick video. - Morgan Worrell

On the other hand, we have solutions like PWAs that allow us to leverage our existing website code to generate an app-like feeling version of our website that users can use instead.

I think what's popular nowadays is building PWAs. This will basically be an a web app, but it can act as a kind of native app within the mobile device. That would definitely cut us some time to deliver it more quickly, especially in the beginning. - Chris Trzesniewski

Going purely native requires us to hire speciality developers in Objective-C and Java and maintain 3 different code bases: web, iOS, and Android. But is it worth going down this path?

The average mobile user installs zero apps per month. - Rob Ocel

Mobile Device Differences

A key problem with supporting multiple devices is the look and feel of the app on different devices. Users on different devices have expectations of how apps should work on their respective device. Forgetting some of these details can even be detrimental to your overall build and leave your app feeling boring or lackluster.

You can see a picture of the app without seeing the device frame itself and you can go 'that's an Android app' or 'that's an iOS app' and there's a lot of those subtle differences. - Rob Ocel

So how do we keep our app engaging? What can we do to drive traffic into the application and keep users active in the community?

Gamification

Creating feedback driven interactive features can be the major differentiator. Look at how other companies or products in the same or similar space are doing things. On one hand, you could go the social route like Untappd where you can keep a rating of all the different drinks you've tried and share with your friends, which then gives you badges and other little gamey features. On the other, you could try to follow the Yelp model where you become an amateur food critic and others can follow you to get opinions on restaurants to try. You could also go the StackOverflow approach where different actions get you points in some internal "ranking" system.

Do we really need both then?

For speed, we've decided that a website is the most practical approach. There are certain features of a mobile device, like its constant availability and camera, that make it a must have for our app. Because we decided on a website approach, though, that means our app is accessible from a desktop so it needs to look good here as well. Using CSS responsive design practices, we can easily achieve a site that looks good on both desktop devices and mobile devices.

Post MVP

Eventually, we might want to have a native app to get some of the other awesome features that the mobile hardware allows that aren't necessarily available through the web version of the app. This will lead us to an eventual migration, but one we can focus on more intentiontally after the initial launch.

All migrations are effort. It's just whether you're going to spend the effort or not. Sometimes there's more mandatory upfront work and other times there's a lot of hidden work that's sort of labeled optional. - Rob Ocel

Moderation

Our app is allowing arbitrary data from the community and isn't in any way curated. This means we could get some content we don't necessarily want such as expletives, rude or harmful messaging, or inappropriate images. What are strategies we could employ to counter this risk? Are there ways to automate these processes? How can we build these tools and processes in a way that scale with our community growth? Our business doesn't necessarily want to commit dedicates resources full time to this process long-term so how can we work around this problem?

Basic Version

An early version of the app might do some simple content filtering and moderation. We could have a list of words we don't want to be posted and use a CMS system to keep that list updated. We then can filter out words that are on the list from appearing on the site through algorithms to censor those words or just to change the display settings on the site to hide these words.

We could also build some basic moderation tooling to allow admins to delete inappropriate posts and ban users from using the site. These features could be combined with a reporting system where community members can flag certain content as inappropriate.

We could also create moderator roles where we give certain figures in the community to purge bad content or users from our system. This comes with the risk of having moderators who fail to do the role or go on a power trip and delete a bunch of content or ban a bunch of users because they can. The system will need some checks and balances and some data security features like shallow deletes where content isn't actually purged but filtered from appearing on the UI.

Negative Side Effects of Moderation

We have to be careful about our implementation of moderation as it could lead to a subpar community where there is snobbery or other forms of toxicity that we don't want. If we choose an AI or the wrong moderators, this could lead to a down turn in community sentiment. We maybe want to run experiments with tools like IBM Watson's sentiment analysis or other AIs to see what would happen.

We also have to be wary of what happens when our moderation mode of choice stops operating at optimal capacity. Do we have a fall back plan that works? Is there any redundancy in our system to prevent any outages in moderation tooling?

Positive Moderation

We also want to encourage people for contributing positively. We could build quick and simple features of awarding a user a point in a commendation category where they prove to be an expert in certain areas. It encourages them to engage more and let's them become a community leader chosen by the community.

Where does the moderation tooling live?

We can build the moderation tooling in its own separate admin application. Alternatively, we could follow the YouTube model where everything lives inside the main user interface. Given our goal to have a single app for users and desire to leverage the community, it probably makes the most sense for our application to have the tooling live alongside the main application.

Let's say performance. Yes, there are things like code splitting, but how many additional bytes over the wire are you going to send down for, to in-service of an admin portal that maybe 99% of your users will never see? And again, there are ways to mitigate that, but you know, that's another thing to consider: do you really want to ship two completely orthogonal experiences in one bundle?

That being said, we should absolutely evaluate how large this additional tooling is and how memory-costly is it going to be to send that to every user.

Conclusion

I want to thank my guests Rob Ocel, Morgan Worrell, and Chris Trzesniewski with This Dot for joining me on Build IT Better. It was an amazing conversation and knowledge share. This article would not be possible without their time and insight. Thank you.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Dustin Goodman
Engineering Manager with a passion for web and application development. Speaker and writer on work experiences and software development. Dog dad and musician fueled by coffee.
@dustinsgoodman @dustinsgoodman

It's Impossible For This Code to Fail - with Loren Sands-Ramshaw

Loren Sands-Ramshaw, Developer Relations Engineer at Temporal joins Rob Ocel to talk about reliable application development. They introduce the topic of durable execution and talk about reliability in systems, unraveling common issues developers face and showcase the benefits that durable execution can bring to software development. They also talk about the challenges of traditional programming and the complexities of event-driven architecture. Listen to the full podcast here: https://modernweb.podbean.com/e/modern-web-podcast-s11e19-its-impossible-for-this-code-to-fail/...

Jan 24, 2024

1 min

ArchitectureJavaScript

Remix Deployment with Architecture

Intro Today’s article, will give a brief overview of the Architect framework and how to deploy a Remix app. I’ll cover a few different topics, such as what Architect is, why it’s good to use, and the issues I ran into while using it. It is a straightforward process, and I recommend using it with the Grunge Stack offered by Remix. So let’s jump on in and start talking about Architect. Prerequisites There are a few prerequisites and also some basic understandings that are expected going into this. The first is to have a GitHub account, then an AWS account, and finally some basic understanding of how to deploy. I also recommend checking out the *Grunge Stack* here if you run into any issues when we progress further. What is Architect? First off, Architect is a simple framework for Functional Web Apps (FWAs) on AWS. Now you might be wondering, "why Architect?" It offers the best developer experience, works locally, has infrastructure as code, is secured to the least privilege by default, and is open-source. Architect prioritizes speed, smart configurable defaults, and flexible infrastructure. It also allows users to test things and debug locally. It defines a high-level manifest, and turns a complex cloud infrastructure into a build artifact. It complies the manifest into AWS CloudFormation and deploys it. Since it’s open-source, Architect prioritizes a regular release schedule, and backwards compatibility. Remix deployment Deploying Remix with Architect is rather straightforward, and I recommend using the Grunge Stack to do it. First, we’re going to head on over to the terminal and run *npx create-remix --template remix-run/grunge-stack*. That will get you a Remix template with almost everything you need. *Generating remix template* For the next couple of steps, you need to add your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to your repo’s secrets. You’ll need to create the secrets on your AWS account, and then add them to your repo. *AWS secrets* *GitHub secrets* The last steps before deploying include giving CloudFormation a SESSION_SECRET of its own for both staging and production environments. Then you need to add an ARC_APP_SECRET. *Adding env variables* ` With all of that out of the way, you need to run *npx arc deploy*, which will deploy your build to the staging environment. You could also do *npx arc deploy —-dry-run* beforehand to verify everything is fine. Issues I Had in My Own Project Now let's cover some issues I had, and my solution for my own project. So, I had a project far into development, and while looking at the Grunge Stack, I was scratching my head, trying to figure out what was necessary to bring over to my existing project. I had several instances of trial and error as I plugged in the Architect related items. For instance: the arc file, which has the app name, HTTP routes, static assets for S3 buckets, and the AWS configuration. I also had to change things like the *remix.config* file, adding a *server.ts* file, and adding Architect related dependencies in the package.json. During this process, I would get errors about missing files or missing certain function dirs(), and I dumped a good chunk of time into it. So while continuing to get those errors, I concluded that I would follow the Grunge Stack, and their instructions for a new project. Then I would merge my old project with the new project; and that resolved my issues. While not the best way, it did get me going, and did not waste any more time. That resolved my immediate issues of trying to get my Remix app deployed to AWS, but then I had to figure out what got pushed. That was easy, since it created a lambda, API gateway, and bucket based on the items in my arc file. Then I realized, while testing it out live, that my environmental variables hadn’t carried over, so I had to tweak those on AWS. My project also used a GitHub OAuth app. So that needed to be tweaked with the new URL. Then it was up and running. Conclusion Today’s article covered a brief overview of what Architect is, why it’s good to use, how to deploy a Remix app and the issues you might have. I hope it was useful and will give others a good starting point....

Aug 30, 2022

4 mins

RemixOpen SourceArchitectureAWS

The Dangers of ORMs and How to Avoid Them

Background We recently engaged with a client reporting performance issues with their product. It was a legacy ASP .NET application using Entity Framework to connect to a Microsoft SQL Server database. As the title of this post and this information suggest, the misuse of this Object-Relational Mapping (ORM) tool led to these performance issues. Since our blog primarily focuses on JavaScript/TypeScript content, I will leverage TypeORM to share examples that communicate the issues we explored and their fixes, as they are common in most ORM tools. Our Example Data If you're unfamiliar with TypeORM I recommend reading their docs or our other posts on the subject. To give us a variety of data situations, we will leverage a classic e-commerce example using products, product variants, customers, orders, and order line items. Our data will be related as follows: The relationship between customers and products is one we care about, but it is optional as it could be derived from customer->order->order line item->product. The TypeORM entity code would look as follows: ` With this example set, let's explore some common misuse patterns and how to fix them. N + 1 Queries One of ORMs' superpowers is quick access to associated records. For example, we want to get a product and its variants. We have 2 options for writing this operation. The first is to join the table at query time, such as: ` Which resolves to a SQL statement like (mileage varies with the ORM you use): ` The other option is to query the product variants separately, such as: ` This example executes 2 queries. The join operation performs 1 round trip to the database at 200ms, whereas the two operations option performs 2 round trips at 100ms. Depending on the location of your database to your server, the round trip time will impact your decision here on which to use. In this example, the decision to join or not is relatively unimportant and you can implement caching to make this even faster. But let's imagine a different situation/query that we want to run. Let's say we want to fetch a set of orders for a customer and all their order items and the products associated with them. With our ORM, we may want to write the following: ` When written out like this and with our new knowledge of query times, we can see that we'll have the following performance: 100ms * 1 query for orders + 100ms * order items count + 100ms * order items' products count. In the best case, this only takes 100ms, but in the worst case, we're talking about seconds to process all the data. That's an O(1 + N + M) operation! We can eagerly fetch with joins or collection queries based on our entity keys, and our query performance becomes closer to 100ms for orders + 100ms for order line items join + 100ms for product join. In the worst case, we're looking at 300ms or O(1)! Normally, N+1 queries like this aren't so obvious as they're split into multiple helper functions. In other languages' ORMs, some accessors look like property lookups, e.g. order.orderItems. This can be achieved with TypeORM using their lazy loading feature (more below), but we don't recommend this behavior by default. Also, you need to be wary of whether your ORM can be utilized through a template/view that may be looping over entities and fetching related records. In general, if you see a record being looped over and are experiencing slowness, you should verify if you've prefetched the data to avoid N+1 operations, as they can be a major bottleneck for performance. Our above example can be optimized by doing the following: ` Here, we prefetch all the needed order items and products and then index them in a hash table/dictionary to look them up during our loops. This keeps our code with the same readability but improves the performance, as in-memory lookups are constant time and nearly instantaneous. For performance comparison, we'd need to compare it to doing the full operation in the database, but this removes the egregious N+1 operations. Eager v Lazy Loading Another ORM feature to be aware of is eager loading and lazy loading. This implementation varies greatly in different languages and ORMs, so please reference your tool's documentation to confirm its behavior. TypeORM's eager v lazy loading works as follows: - If eager loading is enabled for a field when you fetch a record, the relationship will automatically preload in memory. - If lazy loading is enabled, the relationship is not available by default, and you need to request it via a key accessor that executes a promise. - If neither is enabled, it defaults to the behavior ascribed above when we explained handling N+1 queries. Sometimes, you don't want these relationships to be preloaded as you don't use the data. This behavior should not be used unless you have a set of relations that are always loaded together. In our example, products likely will always need product variants loaded, so this is a safe eager load, but eager loading order items on orders wouldn't always be used and can be expensive. You also need to be aware of the nuances of your ORM. With our original problem, we had an operation that looked like product.productVariants.insert({ … }). If you read more on Entity Framework's handling of eager v lazy loading, you'll learn that in this example, the product variants for the product are loaded into memory first and then the insert into the database happens. Loading the product variants into memory is unnecessary. A product with 100s (if not 1000s) of variants can get especially expensive. This was the biggest offender in our client's code base, so flipping the query to include the ID in the insert operation and bypassing the relationship saved us _seconds_ in performance. Database Field Performance Issues Another issue in the project was loading records with certain data types in fields. Specifically, the text type. The text type can be used to store arbitrarily long strings like blog post content or JSON blobs in the absence of a JSON type. Most databases use a technique that stores text fields off rows, which requires a special file system lookup operation to fetch that data. This can make a typical database lookup that would take 100ms under normal conditions to take 200ms. If you combine this problem with some of the N+1 and eager loading problems we've mentioned, this can lead to seconds, if not minutes, of query slowdown. For these, you should consider not including the column by default as part of your ORM. TypeORM allows for this via their hidden columns feature. In this example, for our product description, we could change the definition to be: ` This would allow us to query products without descriptions quickly. If we needed to include the product description in an operation, we'd have to use the addSelect function to our query to include that data in our result like: ` This is an optimization you should be wary of making in existing systems but one worth considering to improve performance, especially for data reports. Alternatively, you could optimize a query using the select method to limit the fields returned to those you need. Database v. In-Memory Fetching Going back to one of our earlier examples, we wrote the following: ` This involves loading our data in memory and then using system memory to perform a group-by operation. Our database could have also returned this result grouped. We opted to perform this operation like this because it made fetching the order item IDs easier. This takes some performance challenges away from our database and puts the performance effort on our servers. Depending on your database and other system constraints, this is a trade-off, so do some benchmarking to confirm your best options here. This example is not too bad, but let's say we wanted to get all the orders for a customer with an item that cost more than $20. Your first inclination might be to use your ORM to fetch all the orders and their items and then filter that operation in memory using JavaScript's filter method. In this case, you're loading data you don't need into memory. This is a time to leverage the database more. We could write this query as follows in SQL: ` This just loads the orders that had the data that matched our condition. We could write this as: ` We constrained this to a single customer, but if it were for a set of customers, it could be significantly faster than loading all the data into memory. If our server has memory limitations, this is a good concern to be aware of when optimizing for performance. We noticed a few instances on our client's implementation where the filter operations were applied in functions that appeared to run the operation in the database but were running the operation in memory, so this was preloading more data into memory than needed on a memory-constrained server. Refer to your ORM manual to avoid this type of performance hit. Lack of Indexes The final issue we encountered was a lack of indexes on key lookups. Some ORMs do not support defining indexes in code and are manually applied to databases. These tend not to be documented, so an out-of-sync issue can happen in different environments. To avoid this challenge, we prefer ORMs that support indexes in code like TypeORM. In our last example, we filtered on the cost of an order item, but the cost field does not contain an index. This leads to a full table scan of our data collection filtered by the customer. The query cost can be very expensive if a customer has thousands of orders. Adding the index can make our query super fast, but it comes at a cost. Each new index makes writing to the database slower and can exponentially increase the size of our database needs. You should only add indexes to fields that you are querying against regularly. Again, be sure you can notate these indexes in code so they can be replicated across environments easily. In our client's system, the previous developer did not include indexes in the code, so we retroactively added the database indexes to the codebase. We recommend using your database's recommended tool for inspection to determine what indexes are in place and keep these systems in sync at all times. Conclusion ORMs can be an amazing tool to help you and your teams build applications quickly. However, they have gotchas for performance that you should be aware of and can identify while developing or during code reviews. These are some of the most common examples I could think of for best practices. When you hear the horror stories about ORMs, these are some of the challenges typically discussed. I'm sure there are more, though. What are some that you know? Let us know!...

Jul 3, 2024

8 mins

Architectural DesignDesign PatternsArchitecture

Learning Paths for Next.JS Developers with Ankita Kulkarni

In this video, Rob Ocel and co-hosts Tracy Lee, Adam Rackis, and Danny Thompson talk with tech educator Ankita Kulkarni about her journey from engineering leader to full-time educator. Ankita shares insights on teaching Next.js, bridging practical knowledge gaps, and helping developers tackle real-world challenges. They discuss Next.js as a React-based framework, its benefits, and the challenges it presents for beginners. Chapters - Introduction to the Podcast and Guests 00:01 - Meet Ankita Kulkarni, Tech Educator 00:26 - Ankita's Transition to Full-Time Education 01:41 - Teaching Practical Knowledge in Next.js 03:19 - Effective Methods for Teaching Next.js 05:27 - Challenges of Being a Full-Time Educator 07:48 - Balancing Broad and Specific Examples 09:54 - Embracing Mistakes as a Teaching Tool 12:13 - Pair Programming and Mentorship 14:00 - Discussion on Next.js and Framework Adoption 16:48 - Advantages and Challenges of Next.js 18:12 - Choosing the Right Framework for Your Needs 20:35 - Impact of Next.js in React Documentation 22:26 - Learning Paths for New Developers 23:24 - The Rise of Full-Stack Web Development 25:09 - Benefits of Frameworks Abstracting Complexity 26:27 - OpenNext and Deployment Flexibility 28:06 - Ankita's Excitement for New Next.js Features 30:35 - The Future of Next.js Without Vercel 32:16 - Final Thoughts and Where to Find Everyone Online 34:21 Follow Ankita Kulkarni on Social Media Twitter: https://x.com/kulkarniankita9 YouTube: https://www.youtube.com/@kulkarniankita Sponsored by This Dot: thisdot.co...

Nov 12, 2024

2 mins

NextJSJavaScript

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Building a Multi Platform Community Engagement Tool

Intro

Mobile & Desktop

Mobile Device Differences

Gamification

Do we really need both then?

Post MVP

Moderation

Basic Version

Negative Side Effects of Moderation

Positive Moderation

Where does the moderation tooling live?

Conclusion

Dustin Goodman

You might also like

It's Impossible For This Code to Fail - with Loren Sands-Ramshaw

Remix Deployment with Architecture

The Dangers of ORMs and How to Avoid Them

Learning Paths for Next.JS Developers with Ankita Kulkarni

Let's innovate together!

You might also like

It's Impossible For This Code to Fail - with Loren Sands-Ramshaw

Remix Deployment with Architecture

The Dangers of ORMs and How to Avoid Them

Learning Paths for Next.JS Developers with Ankita Kulkarni