Parse Laravel Package

Getting Started

1. Install with Composer alongside the Parse PHP SDK the package depends on:

   composer require parziphal/parse
   

2. Publish the package config (typically config/parse.php) and wire credentials in .env: PARSE_APP_ID, PARSE_REST_KEY, PARSE_MASTER_KEY (server-side only), and PARSE_SERVER_URL pointing at your Parse Server (or https://api.parse.com/1 if you're still on legacy Parse—unlikely today).
3. Look first at the package's Model base class in src/. Everything hinges on it: it proxies attribute access to a backing Parse object and exposes static query/find entry points. Skim the README examples before writing code—the Eloquent-shaped surface hides a much smaller feature set than Eloquent.
4. Define your first model by extending the base class and declaring the Parse class name:

   use Parse\Model;
   
   class Post extends Model
   {
       protected $className = 'Post';
   }
   

5. First use case almost everyone hits: read a record and mutate it.

   $post = Post::find('abc123objectId');
   $post->title = 'Hello Parse';
   $post->save();
   

   This is the shortest path to verifying config, credentials, and the class-name mapping all work together.

Implementation Patterns

Model-per-Parse-class. Treat each Parse class as an Eloquent-style model. That gives you find, where(...)->get(), first(), save(), delete(), plus attribute get/set. Keep model classes thin—there's no migration, no schema, and no observer system to hang logic on.

Query building mirrors Eloquent, not Parse. Prefer the fluent style so your code stays portable:

$posts = Post::where('published', true)
    ->where('createdAt', '>', $since)
    ->orderBy('createdAt', 'desc')
    ->limit(25)
    ->get();

Fall back to the raw Parse SDK query ($post->query()) only when you need Parse-only operators (geo, regex, $inQuery, $relatedTo).

Pointers and relations. Parse relationships are pointer fields, not Laravel relations. Load related objects explicitly—either by fetching the pointer's objectId and calling Related::find($id), or by using include() in the query so the pointer resolves in one round trip. There is no lazy-loading; if you expect $post->author to be a model instance, you must include it.

Server-side controllers. This package shines in Laravel controllers/jobs where you act as a trusted backend: use the master key in config so you can read protected classes, bypass ACLs, and query users. Never ship the master key to the client—this package assumes server execution.

Auth flows. For signup/login, use the Parse SDK's user class directly rather than shoehorning it through models. On success, persist the session token in your Laravel session and reconstruct the user on subsequent requests via the SDK's become().

Bulk writes. save() is one object per call. For imports, batch by instantiating many models and saving in a loop, or drop to the SDK's batch request support—wrap it in a Laravel job so it can retry.

Gotchas and Tips

• Stale dependency surface. Last release was May 2020. It targets older Parse PHP SDK versions and Laravel 5/6-era conventions. Expect to pin the SDK version and test against your Laravel version; don't assume composer require just works on newer Laravel.
• No migrations, no schema safety. Parse classes accept arbitrary fields. Typos silently create new columns—write tests or validation around model fields.
• Class-name casing matters. Parse class names are case-sensitive; a protected $className mismatch with the actual class on the server yields empty results rather than an error. Log the resolved class name when debugging "why is my query empty."
• Default query limit is 100. Parse caps results per request. Paginate explicitly with skip/limit or you'll silently truncate large result sets.
• Date handling. Parse stores dates as its own ParseDateTime type; the package's attribute access may hand you strings or Parse date objects rather than Carbon. Convert at the boundary (a small accessor/mutator on your model) so the rest of your app deals only in Carbon.
• Master key vs REST key. If queries mysteriously return 403/empty, check which key is configured. Dev with REST key, prod with master key is a common footgun—use separate .env values per environment.
• Debugging. The underlying Parse SDK has its own logging; enable it or inspect the raw HTTP via an HTTP client proxy. Errors from Parse (code + message) are usually surfaced as exceptions from the SDK—catch ParseException and translate to your app's domain errors rather than letting Parse codes leak to users.
• Extension points. The base Model is the place to extend: add $fillable-style guards, custom casts, or a boot hook for common scopes. Keep the subclasses minimal so upgrades to the package remain trivial.
• Consider the exit ramp. Given the package's age and low maintenance, isolate Parse access behind repository interfaces so you can swap to direct parse/php-sdk calls or a newer Eloquent-like wrapper without touching domain code.