One of my biggest frustrations with apps is the 30 character limit for the app name.
I understand that this may be needed for apps on the app store, however when it comes to custom apps it can be a problem.
Agencies can have multiple apps for multiple clients that also have multiple environments.
A custom app name often needs to include the client name, some kind of app name and then perhaps whether it’s for dev, staging or production. This often means we have to use abbreviations for app names to be under 30 chars.
Not sure what the solution could be but raising the char limit would be helpful.
@lukeclifton I work on our developer platform and was a part of the team that worked on this. The rationale for this is around merchant experience. We want the left hand side of the admin to be an easy way for merchants to navigate to key features (e.g. Orders, Discounts etc.) and apps and so the constraint of short names keeps the navigation tidy and reduces cognitive load.
Given your use case abbreviations is a reasonable approach.
Thanks @eytan-shopify Good to understand the rationale here.
Abbreviations are far from ideal though. When you have multiple clients and 100’s of apps it can be very hard to find and search for the app you’re looking for within the Partners account.
I think increasing the char limit slightly would help. 30 chars has always felt small.
However perhaps a tagging feature for apps would also help here.
My thought was this where you could hover over the app name to display the full one in a tooltip or simply have it auto scroll over to the end as you’re hovering it…
Another thought here is having 2 fields, one public-facing and one for the partners side of thing so that finding the app there is easier.
I agree with Eytan here. Over the last decade I’ve been building custom apps for merchants and my partner account is full of it. We took two steps:
Create custom apps from the Merchant’s Store, if they needed multiple smaller apps.
For more complicated and super apps, like Eytan said, we use abbreviations. The naming convention is usually App Name [AB] and it has been working great.
I believe another thing that you can do is combine the multiple smaller apps for the same merchant into one, for the lack of a better term, super app. This has been great to cut down on app installs, easier to track things and hosting has been straight forward.
We use a pure JS stack, so throwing that in a VPS has been working great, database is on PlanetScale, Cloudflare CDN to cache assets and some requests, and the recently introduced Managed Webhooks to ensure we process only required webhooks and divide what routes process which webhooks. This makes updating apps to the latest API versions also much easier.
A problem that came up was rate limiting (rare, but happened), and moving to bulk operations, queues and creating a new custom app from Merchant’s dashboard and delegating some tasks to that instance of shopifyApi has worked out great, so from our Partner dashboard we only have 1 super app, and for working around rate limits we pull from merchant’s custom apps space.
A thing to note here is that this isn’t a workaround (the API rate limit is) but unification of code from microservices to a monolith has made things easier to update, especially when you can write codemods to bulk update 100s of apps at once.
@kinngh I think the topic you raise here is a different discussion.
We do for sure build apps directly in a client’s own partners account at times but we also manage apps for clients in our own partners account too or at least have development versions.
Regards whether to run with multiple apps or a monolith app for a client, we also use both strategies depending on the client / architecture discussions.
However, none of this changes the problem of it being hard to find and search for apps when you have hundreds of apps in your partners account, with names that are abbreviated or not fully descriptive.
In some cases a custom app name still has to try and describe:
Client name
App description
Environment (This might even need to include a devs name)
I still disagree. For multiple environments, we took the approach of creating a partner account just for dev environments while our actual Partner account had production environments set up.
But then again, this is how we’ve been doing since the last decade and it’s been working out for us really well.
@lukeclifton It helps to understand the aspects that go into your app naming (client name, app description and environment). One of the issues with our dev platform is the fact that you basically need to have a separate app for each environment (dev, staging, prod). And your setup is not unusual - I see this all the time.
This is an anti-pattern and something that you shouldn’t have to do - the dev platform should have better native support for environments so you don’t have to manage so many apps. That’s something we are going to be working on next year and so we should be in touch when we get to that point.
I say all of that because if you had 30 characters for client name and a short app description than this might be less of an issue?
@eytan-shopify Yes if a single app could support multiple environments, this would be a far bigger needed improvement and would definitely help towards the naming frustration! It will be awesome when apps support multiple envs.
Some kind of tagging or a internal app name could still be a helpful feature though.
I should add that the naming issue I mention is definitely more of an issue when the agency size includes a large dev team (like 50+ devs) and hundreds of apps are being managed.
