If I am building a site with a landing page and a few info pages that aren’t database related…
let’s say we have:
index (landing page)
pricing
FAQ
about
…
all in subdirectories of example.com
is it possible to keep just the Backendless content on a dedicated subdomain like app.example.com?
I was thinking that the two purposes are different, and I would want reserve Backendless plan usage for powering user-related functionality. For static frontend pages that serve to promote awareness of my web app’s service and provide customers with information, but don’t rely on the database, I want those to reside on the domain.
content type:
static web pages
dynamic pages / app
uses Backendless?
No
Yes
must be logged in to view?
No
Yes
hosted on:
example.com
app.example.com
purpose:
search engine visibility
providing service to customers
is part of mobile app?
No
Yes
(We assume here that users of the mobile app don’t need the landing page info stuff to be included in the mobile app - they can visit the website using their device’s browser to access that info.)
How would one go about setting up an app with this structure?
Thanks.
That tutorial is easy to follow, and answered most of my questions.
Which API requests can be moved to another web host, and which need to go through Backendless?
I still don’t have a deep understanding of how API requests work.
When you move your files to a CDN (or any other web host), the file download requests will not hit Backendless. However, your UI pages (even loaded from another web host) can still send requests to Backendless for everything else (database, user registration/login/logout/etc, messaging, API services).
Thank you for the reply.
That information is helpful.
Please let me know if I am understanding this correctly:
API calls to the database that is hosted and managed through Backendless, are the ones that will have an impact on monthly cost. Whereas retrieving files like images for the site design could be done through the other web host and not be counted.
Certain files, such as user profile content, would need to stay private and be only served to other users who are logged in and have viewing privileges… so content like that would use Backendless API calls.
Questions regarding cost:
I am looking at the Scale Plan pricing that advertises “unlimited API requests/month”.
But then I see the “Increasing Limits” section on the same page, and there are significant price increases for activity such as messages, notifications, and real-time connections.
Below that there is the “Scale Pricing Tiers” section which appears to indicate that any number of requests per minute above zero will add substantially to the cost of the plan.
After reading the pricing details more carefully, I’m not confident that I understand the pricing model.
I had typed out a long draft detailing all my questions, but instead I will try to ask in the simplest way:
Can I realistically launch an app for $15/month, cap API usage to prevent exceeding that amount, and then over time raise the limits and pay more to offer a more responsive experience to users of my app?
Scaling gradually is what I need to do as I monetize my app over time. So I hope the Scale Plan can be a solution for me.
It is simpler than that - when you move your files outside of Backendless, the requests to fetch the files (HTML/JS/CSS/Images/etc) are not counted. Everything else, and by that, I mean all API calls (User Service, Data Service, Messaging Service, Custom APIs), are counted.
The $15/month price results from the app staying in the Tier 1 (see the “How Tiered Pricing Works” section). If the app’s usage (as translated to the number of API calls it makes) generated by all users of your app results in 0-5 requests per minute, then yes, the monthly fee would be $15.
Thank you. The “Tiered Pricing” page is very informative.
Is there a safety feature I can enable to deny requests beyond a certain tier?
By “deny” I mean - throttle, queue, or stagger timing of API requests,
in order to safeguard against unexpectedly high fees.
Without such a feature I think it will be difficult to anticipate how high the cost of running the app will be.
Since I don’t see any mention of such a safety cap, I’m going to make a separate post about it as a suggestion.
(The reply I was drafting grew longer than I expected, and has become a topic of its own.)
If it turns out that such a feature already exists, feel free to disregard my suggestion.
Yes, there is. When your app is on the Scale plan, you get the following option on the Manage > Billing screen (read the text in the highlighted section):
