https:\/\/yourproject.supabase.co<\/code>) is your API endpoint. These credentials are all you need to start interacting with your database from your frontend or backend.<\/p>\nNow, let\u2019s create a simple schema. In Supabase, you can use the SQL Editor to write raw SQL \u2013 a huge advantage over Firebase\u2019s constrained console. Navigate to the \u201cSQL Editor\u201d and paste the following script to create a todos<\/code> table and an accounts<\/code> table (wil be useful for authentication later):<\/p>\n-- Create accounts table (linked to Supabase auth users)\nCREATE TABLE public.accounts (\n id uuid NOT NULL PRIMARY KEY,\n email text,\n created_at timestamptz DEFAULT now(),\n updated_at timestamptz DEFAULT now()\n);\n\n-- Create todos table\nCREATE TABLE public.todos (\n id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,\n user_id uuid NOT NULL REFERENCES public.accounts(id) ON DELETE CASCADE,\n title text NOT NULL,\n is_complete boolean DEFAULT false,\n inserted_at timestamptz DEFAULT now()\n);\n\n-- Enable Row Level Security\nALTER TABLE public.todos ENABLE ROW LEVEL SECURITY;\nALTER TABLE public.accounts ENABLE ROW LEVEL SECURITY;<\/code><\/pre>\nAfter running this, you have two tables. You\u2019ll also see that Supabase automatically created a table called auth.users<\/code> where authentication records live. We\u2019ll tie our accounts<\/code> table to those users via triggers (optional, but useful). For a quick test, go to the \u201cTable Editor\u201d and manually insert a couple of todos. You\u2019ll notice that the UI resembles a traditional database GUI \u2013 you can browse, filter, and edit rows. This is a massive improvement over Firebase\u2019s document view, especially when you have relational data. Now that your database and project are ready, let\u2019s move on to authentication.<\/p>\nStep 2: Implementing Authentication (Email\/Password and OAuth)<\/h2>\n
Supabase Authentication is built on top of GoTrue, the same underlying technology used by Netlify Identity. It supports email\/password, magic links, phone (SMS), and many social providers (Google, GitHub, Facebook, etc.) with a single API. To activate a provider, go to the dashboard -> \u201cAuthentication\u201d -> \u201cSettings\u201d and enable the \u201cEmail\u201d provider. For production, you\u2019ll configure the SMTP server to send real emails. For testing, Supabase provides a fake email service that shows confirmation codes in the dashboard logs. Next, to integrate authentication into your code, install the Supabase JavaScript client library:<\/p>\n
npm install @supabase\/supabase-js<\/code><\/pre>\nThen initialise the client with your project URL and anon key:<\/p>\n
import { createClient } from '@supabase\/supabase-js'\nconst supabase = createClient('https:\/\/yourproject.supabase.co', 'your-anon-key')<\/code><\/pre>\nNow implement a sign\u2011up form. Use supabase.auth.signUp()<\/code> and store the user\u2019s email and password. After sign\u2011up, a user is created in auth.users<\/code>. However, to mirror our accounts<\/code> table, we need to insert a row when a new user signs up. The recommended pattern is to use a database trigger inside PostgreSQL. In the SQL Editor, run:<\/p>\n-- Function to copy user data to accounts\nCREATE OR REPLACE FUNCTION public.handle_new_user()\nRETURNS trigger AS $$\nBEGIN\n INSERT INTO public.accounts (id, email, created_at, updated_at)\n VALUES (NEW.id, NEW.email, now(), now());\n RETURN NEW;\nEND;\n$$ LANGUAGE plpgsql SECURITY DEFINER;\n\n-- Trigger after insert on auth.users\nCREATE TRIGGER on_auth_user_created\n AFTER INSERT ON auth.users\n FOR EACH ROW EXECUTE FUNCTION public.handle_new_user();<\/code><\/pre>\nNow every new user automatically gets a corresponding row in accounts<\/code>. Logging in is equally simple: use supabase.auth.signInWithPassword()<\/code>. The client automatically handles JWT management, refreshes tokens, and stores the session. For social logins, call supabase.auth.signInWithOAuth({ provider: 'github' })<\/code>. Supabase will redirect the user to GitHub, then back to your app. Your app can listen to auth state changes with supabase.auth.onAuthStateChanged()<\/code>. This listener fires when the user logs in, logs out, or when the token refreshes \u2013 perfect for updating your UI. One critical point: never call authentication methods with the service_role<\/code> key client\u2011side. That key bypasses Row\u2011Level Security and should only be used in server\u2011side or backend contexts.<\/p>\nStep 3: Enforcing Row\u2011Level Security (RLS) with Policies<\/h2>\n
Supabase\u2019s security model is fundamentally different from Firebase. Firebase uses security rules written in a proprietary JSON syntax. Supabase leverages PostgreSQL\u2019s built\u2011in Row\u2011Level Security (RLS). With RLS, you write SQL policies that determine which rows a user can see, insert, update, or delete. These policies can reference the authenticated user\u2019s ID (via auth.uid()<\/code>), roles, or even custom claims. Because policies are SQL, they can be extremely powerful \u2013 you can join across tables, use subqueries, and call functions. Let\u2019s create policies for our todos<\/code> table to ensure users only see their own todos.<\/p>\nFirst, make sure RLS is enabled on the table (we did that earlier). Then navigate to the \u201cAuthentication\u201d -> \u201cPolicies\u201d section in the Supabase dashboard, or write SQL directly. I prefer SQL for clarity. Run these policy statements:<\/p>\n
-- Allow users to SELECT only their own todos\nCREATE POLICY \"Users can view their own todos\"\nON public.todos FOR SELECT\nUSING (auth.uid() = user_id);\n\n-- Allow users to INSERT todos with their own user_id\nCREATE POLICY \"Users can insert their own todos\"\nON public.todos FOR INSERT\nWITH CHECK (auth.uid() = user_id);\n\n-- Allow users to UPDATE only their own todos\nCREATE POLICY \"Users can update their own todos\"\nON public.todos FOR UPDATE\nUSING (auth.uid() = user_id);\n\n-- Allow users to DELETE only their own todos\nCREATE POLICY \"Users can delete their own todos\"\nON public.todos FOR DELETE\nUSING (auth.uid() = user_id);<\/code><\/pre>\nAfter creating these policies, even if a malicious attacker obtains your anon key (which is public), they cannot read or modify todos belonging to other users. The database engine rejects any query that doesn\u2019t satisfy the policy. This is a huge advantage over Firebase\u2019s client\u2011side rules, which can be accidentally misconfigured. In Supabase, you can test your policies by using the \u201cRun SQL\u201d feature in the dashboard with a simulated role (use set role authenticated<\/code> and set request.jwt.claims...<\/code>). For our accounts<\/code> table, you might want a policy that lets users only see their own account row, but other users (like admins) can see all. RLS scales effortlessly with complex roles.<\/p>\nStep 4: Performing CRUD Operations with the Supabase Client<\/h2>\n
Now that authentication and security are in place, let\u2019s interact with the database from your frontend. The Supabase JavaScript client offers a fluent query builder that translates to SQL under the hood. For basic CRUD, you use supabase.from('todos')<\/code> followed by .select()<\/code>, .insert()<\/code>, .update()<\/code>, or .delete()<\/code>. Remember, because RLS is active, the client automatically includes the user\u2019s JWT in every request, and the database enforces the policies. Here\u2019s an example of fetching todos for the currently logged\u2011in user:<\/p>\nconst { data: todos, error } = await supabase\n .from('todos')\n .select('*')\n .order('inserted_at', { ascending: false })<\/code><\/pre>\nNotice we didn\u2019t add a .eq('user_id', userId)<\/code> filter \u2013 that\u2019s because the RLS policy already restricts the rows to the current user. For inserting a new todo, you don\u2019t need to specify user_id<\/code> manually if you use the auth.uid()<\/code> function in a default value or policy. However, a safer approach is to let the frontend send the authenticated user\u2019s ID (obtained from supabase.auth.user().id<\/code>):<\/p>\nconst user = supabase.auth.user()\nconst { error } = await supabase\n .from('todos')\n .insert({ title: 'Learn Supabase', user_id: user.id })<\/code><\/pre>\nThe client also supports complex queries: filtering by multiple columns (.eq('is_complete', false)<\/code>), joins with other tables (via .select('*, accounts(email)')<\/code>), and even full\u2011text search (.textSearch('title', 'learn')<\/code>). For bulk operations, you can pass an array of objects to .insert()<\/code> or use .upsert()<\/code>. One key difference from Firebase: Supabase uses HTTP\/REST calls by default, not WebSockets, for standard queries. This means you get the reliability of REST with the flexibility of SQL. However, for real\u2011time, you can switch to subscriptions \u2013 covered next.<\/p>\nIt\u2019s also worth noting that Supabase provides client libraries for multiple languages: Python, Dart (Flutter), Swift, Kotlin, and more. The APIs are similar across all of them. If you\u2019re building a mobile app with Flutter, you\u2019ll use supabase-query-builder<\/code> almost identically. The documentation is excellent and the community is growing fast. To give you a quick reference, here\u2019s a table summarising common CRUD methods:<\/p>\n\n\n\n| Operation<\/th>\n | Method<\/th>\n | Example<\/th>\n<\/tr>\n<\/thead>\n |
\n\n| Select rows<\/td>\n | supabase.from('table').select('columns')<\/code><\/td>\nsupabase.from('todos').select('title, is_complete')<\/code><\/td>\n<\/tr>\n\n| Filter<\/td>\n | .eq(column, value)<\/code>, .lt()<\/code>, etc.<\/td>\n.eq('is_complete', false)<\/code><\/td>\n<\/tr>\n\n| Insert<\/td>\n | .insert(object | array)<\/code><\/td>\n.insert({ title: 'Task' })<\/code><\/td>\n<\/tr>\n\n| Update<\/td>\n | .update(object).eq(column, value)<\/code><\/td>\n.update({ title: 'New' }).eq('id', 1)<\/code><\/td>\n<\/tr>\n\n| Delete<\/td>\n | .delete().eq(column, value)<\/code><\/td>\n.delete().eq('id', 1)<\/code><\/td>\n<\/tr>\n\n| Order<\/td>\n | .order(column, { ascending: boolean })<\/code><\/td>\n.order('created_at', { ascending: false })<\/code><\/td>\n<\/tr>\n\n| Pagination<\/td>\n | .range(start, end)<\/code><\/td>\n.range(0, 9)<\/code> \u2013 first 10 rows<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nStep 5: Real\u2011Time Subscriptions (Live Queries)<\/h2>\nOne of Firebase\u2019s killer features is real\u2011time data synchronisation via listeners. Supabase replicates this using PostgreSQL\u2019s built\u2011in logical replication and a WebSocket layer called Realtime (an open\u2011source engine). You can subscribe to changes on any table: insert, update, delete, or even listen to a specific row. This is perfect for chat apps, collaborative editors, dashboards, or any dynamic UI. To use real\u2011time, you first need to enable replication on your table in the Supabase dashboard. Go to \u201cDatabase\u201d -> \u201cReplication\u201d and ensure your table (e.g., todos<\/code>) is listed. By default, Supabase enables replication for all new tables. Then, in your client code, you can set up a subscription:<\/p>\nconst mySubscription = supabase\n .channel('public:todos')\n .on('postgres_changes',\n { event: '*', schema: 'public', table: 'todos' },\n (payload) => {\n console.log('Change received!', payload)\n \/\/ Update your UI state\n }\n )\n .subscribe()<\/code><\/pre>\nThe first argument to supabase.channel<\/code> is a unique channel name \u2013 you can use any string. The on('postgres_changes', ...)<\/code> listener will fire whenever a row in todos<\/code> is inserted, updated, or deleted. You can filter by specific events (event: 'INSERT'<\/code>) or by a specific row ID. Under the hood, Supabase uses PostgreSQL\u2019s WAL (Write\u2011Ahead Log) to capture changes and broadcasts them to all connected clients. The latency is typically under 100ms. One important consideration: real\u2011time subscriptions respect RLS policies. So if a user is not allowed to see a particular row (because the policy blocks SELECT<\/code>), they will not receive the change for that row. This is a subtle but powerful security feature. If you need to listen only to changes that affect the current user, combine the subscription with a filter by user_id<\/code> (though RLS already prevents seeing other rows, the payload still includes the full row \u2013 always check RLS for select).<\/p>\nFor performance, be careful not to create too many subscriptions. Instead of subscribing to every table, consider using a single channel with multiple filters, or use presence and broadcast features (available in Supabase Realtime client) for collaborative features beyond database changes. The Supabase JavaScript client also supports \u201cpresence\u201d (who is online) and \u201cbroadcast\u201d (send messages to other clients) \u2013 both are out\u2011of\u2011the\u2011box. Real\u2011time subscriptions are a huge reason to choose Supabase over a plain PostgreSQL backend. They give you Firebase\u2011like agility without sacrificing the relational model.<\/p>\n Step 6: File Storage (Database as a File System)<\/h2>\nFirebase\u2019s Cloud Storage is a separate product integrated with Authentication. Supabase Storage is similarly integrated, built on top of S3\u2011compatible object storage (default is MinIO, but you can configure S3). You can create buckets, set public\/private access, upload files, and generate signed URLs for temporary access. The beauty is that file access permissions are governed by RLS policies \u2013 yes, you can write SQL policies for storage! Go to the Supabase dashboard -> \u201cStorage\u201d -> \u201cNew bucket\u201d. Create a bucket called avatars<\/code> and set it to \u201cPublic\u201d for testing, or \u201cPrivate\u201d for secure files. For private buckets, you need to create policies. For example, to allow users to only access their own avatar files, you\u2019d write a policy that checks the file path prefix against auth.uid()<\/code>.<\/p>\nUploading a file from the client is straightforward:<\/p>\n const { data, error } = await supabase.storage\n .from('avatars')\n .upload('public\/' + user.id + '\/' + fileName, file)<\/code><\/pre>\nYou can generate a public URL for public buckets: supabase.storage.from('avatars').getPublicUrl(path)<\/code>. For private buckets, generate a signed URL with an expiration time: supabase.storage.from('private-files').createSignedUrl(path, 60)<\/code> \u2013 the link will only be valid for 60 seconds. This is perfect for secure file delivery without exposing your storage keys. Storage also supports resumable uploads for large files, and you can list files in a folder. The entire storage API is RESTful and can be tested with cURL or Postman. Supabase Storage is a fully functional replacement for Firebase Storage, with the added benefit of SQL\u2011style permissions.<\/p>\nStep 7: Edge Functions (Serverless Functions)<\/h2>\nThe final piece of the Firebase alternative puzzle is cloud functions. Firebase Cloud Functions are Node.js functions that run on Google Cloud. Supabase Edge Functions are serverless functions written in TypeScript\/JavaScript that run on Deno Deploy (powered by Deno). They are incredibly fast to cold\u2011start (under 10ms) and can be deployed directly from the Supabase CLI. Edge Functions are ideal for tasks like webhooks, data validation, sending emails, or interacting with third\u2011party APIs. They integrate with your Supabase project via environment variables and can access your database using the supabase-js<\/code> client with the service_role<\/code> key (for admin operations).<\/p>\nTo create an Edge Function, install the Supabase CLI: npm install -g supabase<\/code>. Then run supabase functions new my-function<\/code>. This generates a TypeScript file with a handler that receives a request object. You can use supabase-js<\/code> inside the function to read\/write the database. Deploy with supabase functions deploy my-function<\/code>. Each function gets a public URL like https:\/\/yourproject.supabase.co\/functions\/v1\/my-function<\/code>. You can set authentication requirements (like requiring a valid JWT) in the function handler itself. Because Edge Functions run on Deno, they support TypeScript natively, have access to the standard Web APIs, and can import modules from npm or deno.land. This makes them more modern than Firebase Cloud Functions (which are stuck on Node 18). Supabase also provides a \u201cserve\u201d command for local development, so you can test functions before deploying. With Edge Functions, you can move your backend logic out of the client and into the edge, reducing client complexity and improving security.<\/p>\nTips and Best Practices<\/h2>\nNow that you\u2019ve seen the core features, let\u2019s discuss some best practices to keep your Supabase project scalable, secure, and maintainable. First, always use Row\u2011Level Security<\/strong>. Even if your app is internal and all users are trusted, RLS acts as a safety net to prevent accidental data leaks. Write policies that are as restrictive as possible, and test them thoroughly in the dashboard\u2019s SQL runner. Second, leverage PostgreSQL indexes<\/strong> \u2013 add indexes on columns you frequently filter or sort by (e.g., user_id<\/code>, created_at<\/code>). Supabase doesn\u2019t create indexes automatically for every foreign key. You can create them from the SQL Editor: CREATE INDEX idx_todos_user_id ON public.todos(user_id);<\/code>. This will make queries much faster as your data grows. Third, use TypeScript with Supabase<\/strong>. The official package includes type generation tools (run supabase gen types typescript --linked > database.types.ts<\/code>) that generate TypeScript types from your database schema. This gives you autocomplete and compile\u2011time error checking for all your queries. Fourth, never expose the service_role<\/code> key<\/strong> to the client. That key has full access to your database, bypassing RLS. Keep it in your server or Edge Functions. Fifth, monitor your database performance<\/strong> with Supabase\u2019s built\u2011in logs and the \u201cHealth\u201d section. You can see query performance, slow queries, and connection counts. If you plan to self\u2011host, set up monitoring tools like pg_stat_statements.<\/p>\nFrequently Asked Questions<\/h2>\nQ1: How does Supabase compare to Firebase in terms of pricing?<\/strong>
\nA1: Supabase\u2019s free tier offers 500 MB database, 2 GB bandwidth, and 50,000 monthly active users (for auth) \u2013 quite generous compared to Firebase\u2019s Spark plan (which has limited database operations and no Cloud Functions). Paid plans start at $25\/month and are based on compute usage and storage. Firebase\u2019s Blaze plan charges per operation, which can be unpredictable. Supabase\u2019s pricing is simpler and often cheaper for moderate usage. However, for extremely high reads, Firebase\u2019s Firestore can be more cost\u2011effective due to its analytics\u2011focused pricing. Overall, Supabase is compelling for projects with relational data needs.<\/p>\nQ2: Can I migrate my existing Firebase project to Supabase?<\/strong>
\nA2: Yes, but it requires effort. You\u2019ll need to redesign your data model from NoSQL to relational SQL. Export Firestore collections to JSON, then import them into PostgreSQL using scripts. For authentication, you cannot directly migrate passwords; users must reset them or you can use Firebase\u2019s custom token flow to generate temporary JWTs. Supabase\u2019s community has several migration guides and tools (like firestore-to-supabase<\/code> on GitHub). It\u2019s not a one\u2011click migration, but the long\u2011term benefits often outweigh the cost.<\/p>\nQ3: Does Supabase support offline persistence like Firebase?<\/strong>
\nA3: Not natively. Supabase\u2019s client doesn\u2019t come with a built\u2011in offline database. However, you can combine Supabase with local\u2011first libraries like RxDB<\/a> or WatermelonDB<\/a> for mobile apps. For web, you can cache data in IndexedDB or React Query\u2019s cache. Offline support is a limitation of Supabase compared to Firebase\u2019s Firestore offline mode, but it\u2019s a trade\u2011off for using a real SQL database.<\/p>\nQ4: How do I handle schema migrations in Supabase?<\/strong>
\nA4: Since Supabase is PostgreSQL, you can use any migration tool: the built\u2011in SQL Editor, Flyway<\/a>, Prisma<\/a>, or golang\u2011migrate<\/a>. Prisma is popular because it provides a type\u2011safe ORM and can introspect existing tables. Supabase also offers a \u201cDatabase\u201d section where you can view and alter schemas via a GUI, but for team projects, version\u2011controlled migration files are essential.<\/p>\nQ5: Can I use Supabase with server\u2011side rendering (SSR) frameworks like Next.js or Nuxt?<\/strong>
\nA5: Absolutely. Supabase\u2019s client can be used in Node.js environments. For Next.js, you can use the @supabase\/supabase-js<\/code> package on the server (with service_role<\/code> key for protected API routes) and on the client (with anon key). Supabase also provides a dedicated Next.js helper library (@supabase\/ssr<\/code>) that handles cookie\u2011based sessions for RSC (React Server Components). Similarly, for Nuxt 3, there is the @supabase\/nuxt<\/code> module. Supabase is framework\u2011agnostic and plays well with SSR.<\/p>\nQ6: What about Supabase and real\u2011time scalability?<\/strong>
\nA6: The Realtime engine uses PostgreSQL logical replication, which scales vertically (more powerful DB instance). For very high\u2011frequency updates (thousands per second), you might need to tune PostgreSQL settings or use a dedicated Realtime server. Supabase\u2019s cloud plan offers dedicated Realtime nodes for Pro and Team plans. In self\u2011hosted scenarios, you can deploy multiple Realtime instances behind a load balancer. It\u2019s less turnkey than Firebase\u2019s globally distributed real\u2011time, but for most apps, it\u2019s more than adequate.<\/p>\nConclusion<\/h2>\nSupabase has emerged as the most mature and fully featured open\u2011source alternative to Firebase. In this tutorial, we covered how to set up a project, implement authentication with email and social providers, enforce rock\u2011solid security with Row\u2011Level Security, perform CRUD operations with a flexible client, subscribe to real\u2011time changes, upload files with storage, and extend your backend with Edge Functions. Throughout, you\u2019ve seen that the key differentiator is the use of PostgreSQL \u2013 you get a relational database with joins, views, and SQL functions, while still enjoying the convenience of a managed BaaS. The skills you learn with Supabase are transferable to any SQL\u2011based backend, and the open\u2011source nature guarantees that you are never locked into a proprietary ecosystem. Whether you\u2019re building a simple blog, a complex SaaS, or a real\u2011time chat application, Supabase gives you the tools to move fast without compromising on data integrity or security. Start your next project with Supabase \u2013 your database will thank you.<\/p>\n","protected":false},"excerpt":{"rendered":" How to Use Supabase as a Firebase Alternative: A Complete Step-by-Step Guide For years, Firebase has been the go\u2011to backend\u2011as\u2011a\u2011service (BaaS) for developers who want to ship fast without managing servers. Its real\u2011time database, authentication suite, and cloud functions have powered countless mobile and web applications. However, as projects grow, many developers hit Firebase\u2019s limitations: … <\/p>\n","protected":false},"author":2716,"featured_media":1120,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1121","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-non-category"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts\/1121","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/users\/2716"}],"replies":[{"embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/comments?post=1121"}],"version-history":[{"count":1,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts\/1121\/revisions"}],"predecessor-version":[{"id":1122,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/posts\/1121\/revisions\/1122"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/media\/1120"}],"wp:attachment":[{"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/media?parent=1121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/categories?post=1121"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sumberlaba.com\/index.php\/wp-json\/wp\/v2\/tags?post=1121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
| | | | | | | | | | | | | |
![\"Article](\"https:\/\/sumberlaba.com\/wp-content\/uploads\/2026\/07\/article-1783098077514.jpg\")
<\/p>\n