When we began building our SaaS product Ayrshare, an API that connects to social networks for posting, we strongly felt that we would not be able to tap into our core target market if we only focused on the traditional marketing and engagement route. You know, the same Google ads, general SEO, and blog posts.
Ads, SEO, and “Top 10” posts* have a place in every marketing strategy, but we are developers ourselves. We know how important it is for a developer to research and evaluate a new product. …
This article is not about promises,
Promise.all() function and how you can bring your independently running functions or tasks together into a beautiful result.
As is often the case, an example or use case will prove useful.
Our app Ayrshare’s primary purpose is to provide one API to post across multiple social media networks, such as Twitter, Instagram, Facebook, and LinkedIn.
A user will make an API call (RESTful or via a client package) with the post text, image, and the list of networks to send the post. …
Twitter Fleets are here! They are new. They are exciting. They are innovative. They are…well, kind of a copy of other social networks.
Twitter has entered the ephemeral posting game that players like Snapchat or Instagram stories have been in for a while. They offer a create space to post text, images, videos, or emojis that only stay around for 24 hours. After that, poof, gone.
Why did Twitter create Fleets? Twitter wants to have “healthy conversations” without harassment or nastiness that sometimes happens on Twitter. Hence, Fleets don’t get Retweets, likes, and are not open to public replies. …
If you have a blog or newsletter, you probably have an RSS feed, which simply is the blog’s content in a machine-readable format. You probably also have social media accounts, like Twitter, Facebook, or LinkedIn. With a few simple steps, you can automate the entire process so every time you update your blog a post will go to all your social media accounts.
Here is a snippet of our RSS feed.
<p>How we used Firebase to build Ayrshare</p>
<p>The post <a rel="nofollow" href="https://www.ayrshare.com/our-firebase-tech-stack/">Our Firebase Tech Stack</a> appeared first on <a rel="nofollow" href="https://www.ayrshare.com">Ayrshare - Automate Your Social Media Posts</a>. …
When we started Ayrshare we were keen on using an infrastructure as a service platform and avoid server setup, SSL certs, opening ports, etc. Time to market, right. Amongst the many platforms out there we choose Firebase. It was an easy decision for us since we are very comfortable with Firebase having built, and even sold, apps built upon it. If not Firebase our second choice would have been Netlify.
The first question we asked was, “What we need today?” If came down to a few criteria:
When you manage your social media presence there are two distinct types of posts: manual and automated.
Manual posting and scheduling is when you type up a post and choose a time for it to be published, usually via a scheduling tool (there are some great ones out there).
Automated posting and scheduling is when system generated data automatically posts to your social media networks via your back-end system using an API.
For example, a game company might auto-post when a gamer enters the top-ten leaderboard. Or a news company’ back-end system sees a new breaking headline and automatically schedules…
Building Ayrshare wasn’t easy and we found it took a lot of leg-work to find details on the various social media network…
We’ve all done it 1,000 times: you build a new app and need to add dynamic email functionality. But it seems like every time you’re reinventing the wheel; set up a new email provider, install Handlebars (if you’re not using Handlebars, you really should be), logging, etc.
The Firebase team has recently introduced a slightly simpler email process that I found removes about 20% of the pain: Trigger Email extension. It’s part of the extensions suite of pre-built functions. Note: the extension is officially in Beta, but we’ve been using it at fireRun.io successfully without issue
Before we get into…
Firebase is an amazing comprehensive platform that takes care of a lot of your infrastructure needs without you needing to lift a finger. It even comes with its own CDN (content delivery network) that servers up your static content from edge servers. This means your content will theoretically load nice and fast for your users since it is on servers closer to them.
However, I’m a big fan of putting Cloudflare (or another CDN provider of your choice like Fastly) in front of Firebase, especially because most the functionality you need is free.
Note: I have no association with Cloudflare…
Google’s Firebase is a great system and environment to quickly build web apps. However, there are a few tricky things to work around, such as deploying to different environments.
You can use Firebase’s env config variables, but I find them difficult to manage. More than once I used prod variables in dev!
Here is what I do to create a staging and production environments with different configurations in Firebase.
1. Setup a unique Firebase project for each environment, e.g. Production, Staging, and Development.
2. At a command prompt, assign an alias for each project with:
firebase use --add